Вопрос по дизайну базы данных (дополнительные поля и дополнительная таблица)

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

Сценарий:

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

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

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

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

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

Или,

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

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

Спасибо,

источник

2011-01-13 fjxx

Как вы используете ProductProperties? Есть ли у нас таблица продуктов, которая имеет внешний ключ ProductProperties? –

@Nitin Да, это правильно. – fjxx

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

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

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

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

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

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

источник

2011-01-15 12:56:04 PerformanceDBA

Таблица фильтров является близкой копией таблицы свойств продукта, так как приложение позволяет фильтровать по свойствам продукта, а пользователи могут сохранять созданные ими фильтры. Базовый фильтр использует только 5 свойств, а расширенный фильтр использует все свойства. – fjxx

Также можно нормализовать таблицу свойств продукта, но это значительно увеличит количество соединений. – fjxx

@fjxx. 1) Хорошо, но у вас есть отдельная таблица продуктов. Используете ли вы бесплатное (не-SQL), например My «SQL»)? 2) Итак, каков страх увеличения количества подключений? Такова природа реляционных баз данных. 3) Если вы публикуете свои DDL (таблицы и индексы) и идентифицируете все ProductTypes & Properties каждого из них, я исправлю всю вашу проблему, включая производительность. – PerformanceDBA

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

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

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

источник

2011-01-13 23:28:58

Вопрос по дизайну базы данных (дополнительные поля и дополнительная таблица)

ответ

Смежные вопросы