Дизайн базы данных: множественные потенциальные идентификаторы

Question

При создании таблицы Funds или Assets, я часто сталкиваюсь с той же проблемой: не все Assets имеют одинаковый идентификатор.

Например: 70% имеют ISIN, некоторые из них имеют код bloomberg, некоторые из них имеют, некоторые из них имеют только AccountingID, исходящие из местного пакета учета и т. Д.

Вообще я в конечном итоге, давая эту таблицу суррогатной PK, плюс различные поля для всех возможных идентификаторов (Bloomberg, ISIN, AccoutingID, ..)

я когда-то унаследованную такую ​​базу данных, где разработчик мигрировали альтернативные ключи к дочерний стол [Идентификаторы], исходя из того, что он заранее не знал все возможные альтернативные ключи.

Эта Идентификаторы таблица выглядит следующим образом:

• AssetID (суррогатной один)
• IdentifierType (например: ISIN)
• IdValue

Что является лучшим решением?

Я думаю, что первая (единственная таблица) лучше всего, потому что, даже если я рискую иметь несколько Nulls, ISIN является ISIN и является хорошо определенным атрибутом Fund.

Answer 1

Я бы сделал отдельную таблицу, потому что метод таблицы Идентификатор делает предположения о типе данных idValue. Что делать, если вы получаете что-то новое, которое использует guid, а не int?

Вы все равно можете сделать отдельный столбец для каждого возможного идентификатора актива и сохранить данные об активах в отдельной таблице, которая отделяет суррогатный идентификатор. Подход, который вы принимаете, будет зависеть в основном от того, как вы будете использовать данные и как часто вы можете добавлять новые типы идентификаторов активов.

Answer 2

Это немного зависит от ваших потребностей, но второй подход является более гибким, поскольку вы можете обеспечить разумный интерфейс для вставки новой записи «Идентификатор», которая не требует изменения схемы базы данных.

Это обычно используется, если вы не знаете, сколько идентификаторов может существовать, или если вы знали, что вам нужно добавить больше времени.

Первый подход более простой с точки зрения написания запросов и, если идентификаторы являются статическими, возможно, проще всего использовать.