Существует ли стандарт проектирования БД для использования разных таблиц для разных типов данных?
Недавно я столкнулся с реляционными базами данных, где каждый тип данных имеет свою собственную таблицу данных. например, для string - TableVarchar, number - TableNumber и т. д.
Я видел 2 базы данных опросов, основанных на этой же структуре. не в состоянии понять, почему кто-то проектирует базу данных таким образом. поискал в google стандарт, но не смог найти ни одной зацепки.
Кто-нибудь знает, является ли это стандартным способом решения конкретной проблемы?
Update 1: 17-Sept-2018 - я, вероятно, нашел правильную причину, по которой база данных поддерживалась таким образом. эта структура базы данных может быть использована для многих приложений малого размера без написания одной строки кода для уровня доступа к данным и базы данных.
Он может быть использован для любого типа веб-приложений, таких как опрос, аудит, управление персоналом, счет-фактура, e-com, любой вид веб-приложения для управления, но небольшие.
Эта структура БД может быть использована небольшими внештатными компаниями и командами для доставки своих клиентских приложений в очень короткие сроки, просто создайте интерфейсное приложение, и все готово. скопируйте-вставьте слой доступа к данным и структуру таблиц, и весь ваш бэк-энд готов.
Надеюсь, это будет полезно для других.
Что я уже пробовал:
поискал в google стандарт, но не смог найти ни одной зацепки.
Richard MacCutchan
Таблицы базы данных должны быть связаны с содержимым, а не с типом данных. Например, наличие всех имен клиентов в Строковой таблице и всех номеров их счетов в числовой таблице не имело бы никакого смысла. Как будут связаны их детали?
Richard Deeming
Похоже, они использовали Ан Сущность-Атрибут-Значение[^] модель.
В большинстве случаев это плохой выбор.
Jörgen Andersson
Пока мало информации, но это может быть кто-то, экспериментирующий с индексом Columnstore. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview?view=sql-server-2017.