The datamodel isn't normalised; to be so it would need a separate table as you say. In that regard, it's not particularly good datamodelling practice.

Whether it was done for a good reason or not is difficult to determine. Conceivably, coding simplification or performance may have been motivators. As likely is that the field originally contained one identifier, requirements changed and the devs didn't have time or inclination to re-factor.

Probably more important is whether or not you should refactor yourself. In similar circumstances I would not pre-emptively refactor a case like this by default. I would consider it if one of the following applied:

1. you have evidence that this causes problems e.g. from legacy issue logs
2. you know for a fact that that you'll be making functional changes in that area
3. the code that handles the data is particularly complex and difficult to reason about.

What I would do, and TBH I would recommend this whenever you take over a legacy application, is start a wiki (or equivalent) and document cases like this. For example,

• issues you've found such as the datamodelling wrinkle
• changes you plan to implement
• changes you don't plan to implement but would if there were time
• areas of code that are difficult to reason about
• areas of code that you've found hard to maintain.

I've found that this is a useful aide memoire for me as I work in and/or come back to a codebase. It also can be every helpful to your successor when they, in turn, need to start learning the codebase.

The datamodel isn't normalised; to be so it would need a separate table as you say. In that regard, it's not particularly good datamodelling practice.

Whether it was done for a good reason or not is difficult to determine. Conceivably, coding simplification or performance may have been motivators. As likely is that the field originally contained one identifier, requirements changed and the devs didn't have time or inclination to re-factor.

Probably more important is whether or not you should refactor yourself. In similar circumstances I would not pre-emptively refactor a case like this by default. I would consider it if one of the following applied:

1. you have evidence that this causes problems e.g. from legacy issue logs
2. you know for a fact that that you'll be making functional changes in that area
3. the code that handles the data is particularly complex and difficult to reason about.

What I would do, and TBH I would recommend this whenever you take over a legacy application, is start a wiki (or equivalent) and document cases like this. For example,

• issues you've found such as the datamodelling wrinkle
• changes you plan to implement
• changes you don't plan to implement but would if there were time
• areas of code that are difficult to reason about
• areas of code that you've found hard to maintain.

I've found that this is a useful aide memoire for me as I work in and/or come back to a codebase. It also can be very helpful to your successor when they, in turn, need to start learning the codebase.