Дизайн БД, когда данные о сущности неизвестны?

Question

Мне интересно, будут ли последующие схемы БД иметь последствия позже.Допустим, я пишу объект сущности.Я не уверен, какие свойства place будут храниться в БД.Я собираюсь создать две таблицы: одну для хранения необходимой (или общей) информации, а другую для хранения дополнительной информации.

Таблица 1 - Место

• PK PlaceId
• Имя
• Лат
• Lng
• и т. Д. (все общие поля)

Таблица 2 - PlaceData

• PK DataId
• PK FieldName
• PK FK PlaceId
• FieldData

Сценарий использования

Я хочу, чтобы некоторые посетители имели возможность ввода пользовательских полей о месте.Например, ресторан - это место, в котором может иметь следующие поля: HasParking, HasDriveThru, requireReservation и т. Д. ... но дилер также является местом, и эти поля не имеют смысла дляавтодилер.

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

Общая цель

На моем сайте asp.net MVC (C # / Razor), где я отображаю place,он будет показывать атрибуты в виде неупорядоченного списка, заполненного: SELECT * FROM PlaceData WHERE PlaceId = @0.

Таким образом, мне не нужно будет показывать пустые имена полей в представлении (или делать проверку string.IsNullOrWhitespace() для каждого икаждое поле. Что я был бы вынужден сделать, если бы каждый атрибут был столбцом в таблице.

Я предполагаю, что этот сценарий довольно распространен, но есть ли лучшие способы сделать это? Особенно с точки зрения производительности? Каковы основные недостатки этой схемы

Answer 1

Ваша идея называется таблицей Entity-Attribute-Value и, как правило, является плохой новостью в RDBMS.СУРБД ориентированы на высокоструктурированные данные.

Общие параметры:

1. Дальнейшее моделирование БД в СУБД, что наиболее вероятно, если кто-то сдерживает спецификации отВы.

2. Придерживайтесь СУБД, используя столбцы XML для данных, структура которых является переменной.Это имеет смысл, если относительно небольшая часть вашей схемы хранения данных является полу- или неструктурированной.Если говорить с точки зрения MS SQL Server, эти данные могут быть проиндексированы, и вы можете выполнять проверки на соответствие ваших данных определению схемы XML.

3. Переход к нереляционной БД, такой как MongoDB, Cassandra, CouchDB и т. Д. Это то, что многие социальные сайты, и я подозреваю, сайты блогов работают с.Кроме того, разумно использовать комбинацию RDBMS и нереляционных хранилищ, если это то, что вам нужно.

EAV может привести к беспорядку, потому что вы создаете базу данныхв базе данных и потерять все преимущества, которые может предоставить СУБД (внешние ключи, принудительное применение типов данных и т. д.), а код SQL, необходимый для восстановления ваших объектов, в мгновение ока переходит из лазаньи в феттучини в спагетти.

Учитывая информацию, добавленную в вопрос, было бы неплохо создать столбец PlaceDetails типа XML в таблице Place.Вы также можете разделить этот столбец на другую таблицу с соотношением 1: 1, если этого требуют требования производительности.

Преимущество такого способа состоит в том, что вы можете извлекать данные с помощью очень простого кода SQL, даже используяМетоды XML типа данных для поиска данных.Но этот подход также позволяет выполнять более сложный анализ данных, ориентированный на представление, в C #, который лучше подходит для этой цели, чем T-SQL.

Answer 2

Если вы хотите, чтобы ваше приложение могло создавать свои собственные настраиваемые поля, это хорошая модель.Mantis Bugtracker также использует это, чтобы позволить администраторам добавлять настраиваемые поля в свои заявки.

Если в любом случае это будет программист, который собирается создать поле, ядолжен согласиться с pst, что это скорее преждевременная оптимизация.

Answer 3

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