Использование «номера типа сущности» в идентификаторе записи для идентификации сущности

Question

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

Каждая таблица базы данных ссылается на определенный тип сущности.Например, TBL_Person, TBL_Organisation, TBL_Address.Однако идентификаторы для каждой таблицы всегда начинаются с одной и той же группы цифр, например, все записи TBL_Address начинаются с 1401, все записи TBL_Person начинаются с 1500.После этого добавляется уникальная часть.

Преимущества, которые я вижу, с точки зрения разработки, заключаются в следующем:

• Это огромный база данных (около 600 таблиц, многие из которых имеют более 150 столбцов).Поэтому, если при сканировании таблицы я нахожу столбцы, такие как WId, RId, LId или UnhelpfullyNamed_Id, я сразу узнаю, к чему это относится (благодаря небольшой программе, которую они также предоставили, где вы вводите первыйчетыре цифры, и это говорит вам, что такое сущность и в какой таблице ее найти)
• Они хранят различные вариации сущностей в одной таблице - например, запись TBL_Vehicle может быть Car (1234), Truck(2345), мотоцикл (3456), так что вам не нужно использовать наследование и т. Д., Если это действительно не нужно

Недостатки (в общем смысле, если это было использовано в другом месте) могут быть:

• Поощряет лень с дизайном таблицы - избыточные столбцы, если в одной таблице хранится много типов сущностей
• Добавляет путаницу для разработчика, который не знает об этом

Есть ли термин для этого шаблона / функции дизайна?Есть ли другие известные базы данных, которые реализуют это?Есть ли другие недостатки / преимущества?

Answer 1

Объединяя две части информации в одном поле, этот «дизайн» нарушает принцип атомарность и, следовательно, первую нормальную форму.

Логически, то же самое можно было бы получить с помощью составного первичного ключа {type, id}. Я предполагаю, что решение «объединить» тип и идентификатор было обусловлено их дизайном приложения и желанием иметь «простые» ключи.

Answer 2

В подобных примерах часто используется дизайн базы данных NO . Все спроектировано и реализовано на уровне приложений (может быть ОО), а затем все хранится (сохраняется) где-то - в данном случае в базе данных. База данных - это просто «хранилище под приложением».

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

Может быть или не быть задействованным преобразователь ORM, поэтому, когда дело доходит до этих больших таблиц, вы можете ожидать результат наследования одной таблицы , реализованного средством отображения.