Вопрос проектирования базы данных (дополнительные поля против дополнительной таблицы) - PullRequest
1 голос
/ 14 января 2011

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

Сценарий:

Таблица ProductProperties: 60 полей (внешний ключ ссылается на таблицу Users через поле CreatedBy)

Пользователи таблицы: 5 полей

Приложение также позволяет пользователям создавать базовый и расширенный фильтры .Эти фильтры такие же, как свойства в таблице ProductProperties.Базовый фильтр использует 10 полей, а расширенный фильтр состоит из всех 60.

Теперь я могу либо:

1) Добавить три поля в Table ProductProperties , а именно FilterName, IsAdvancedFilter, IsFilter (что приводит к множеству значений NULL для записей, которые являются фактическими продуктами, но не фильтрами)

Или

2) Создайте таблицу фильтров , котораяпочти точная копия таблицы ProductProperties, в результате чего получаются две большие очень похожие таблицы

Какой дизайн будет лучше?

Спасибо,

Ответы [ 2 ]

1 голос
/ 15 января 2011

Какой дизайн будет лучше?

Ну, не "дизайн", а выбор из двух предложений. Определенно (2)

Что касается дизайна, ProductProperties с 60 полями, нулевыми значениями и очень большими, не нормируется. Итак, первое, что нужно сделать, если вы хотите дизайн или базу данных, это нормализовать зверя.

  • Прямо сейчас вы работаете с плоскими файлами, которые находятся в контейнере, помеченном как «база данных», и вы можете использовать несколько (конечно, не большинство) функций SQL на нем.

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

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

1 голос
/ 14 января 2011

Лучший дизайн - всегда иметь разные «вещи» в разных таблицах. Если фильтр действительно отличается от продукта, смешивание их вместе создаст много головной боли при попытке справиться с ними. Хранение их отдельно устраняет эти головные боли.

Что касается общих столбцов: таблицы не являются классами, это нормально, если некоторые из них имеют общие столбцы.

Заключительная мысль. Когда вы добавляете столбец к одному, вам придется добавить его к другому. Это тривиально по сравнению с головными болями, которые вы получаете, когда разные вещи смешиваются в одной таблице только потому, что они имеют общие значения.

...