Подходящий способ структурировать таблицу базы данных?(пустые столбцы против нескольких таблиц) - PullRequest
0 голосов
/ 10 сентября 2010

Допустим, у нас есть объект с именем Widget, для которого мы можем построить таблицу базы данных.

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

В фазе 1 у нас просто есть виджет с именем и описанием.

widgets
-------
id (PK)
name
description

В фазе 2 наш виджет получает рост и вес.

widgets
-------
id (PK)
name
description
height
weight

В фазе 3 наш виджет получает пункт назначения и стоимость доставки.

widgets
-------
id (PK)
name
description
height
weight
destination
shipping_cost

Приведенная выше схема (для «фазы 3») означает, что запись базы данных для виджета в фазе 1 или 2 будет иметь нулевые значения .

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

widgets
-------
id (PK)
name
description

widget_specs
-------
id (PK)
widget_id (FK)
height
weight

widget_delivery
-------
id (PK)
widget_id (FK)
destination
shipping_cost

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

В принятом ответе будет приведен современный авторитетный источник по теме.

Редактировать : Я чувствую, что это легко может быть спорным, но это также тема, которая должна иметь оправданные плюсы и минусы и, следовательно, авторитетный ответ. Это просто вопрос, который меня беспокоил, потому что я видел, что это было сделано в обоих направлениях без обоснования или рассмотрения альтернативы. Я просто хотел бы знать, какой правильный , в соответствии с текущими типами DBA, устанавливающими тренд.

Ответы [ 2 ]

2 голосов
/ 11 сентября 2010

Нормальная форма (BCNF / 5NF), как правило, является наиболее надежной основой для проектирования базы данных, если вы не найдете веских причин отклониться от нее.Это означает, что схема без нулей должна быть предпочтительной.Нормализация уменьшает избыточные данные и возможность возникновения аномалий и сводит к минимуму встроенные «отклонения» в проекте, облегчая их обслуживание и расширение.

Нули усложняют большинство операций с базой данных и приводят к неверным результатам при выполнении некоторых запросов.Добавляйте нули только в проект, где вы найдете какую-то особую причину для этого - обычно эти причины связаны с ограничениями СУБД, которые не позволяют легко реализовать какое-либо ограничение или другую логику без использования нулей.Также имейте в виду, что всякий раз, когда разработчик базы данных добавляет пустые значения в базу данных, разработчику приложений обычно приходится выполнять дополнительную работу по удалению или скрытию их в интересах конечного пользователя.

Вы можете найти подробные обсуждения нулевых значений.и другие вопросы, связанные с отсутствующими данными в книге Фабиана Паскаля «Практические вопросы управления базами данных», а также в книгах Криса Дейта и работах Е.Ф.Кодда, Витольда Липски и многих других.

1 голос
/ 10 сентября 2010

Вы можете уменьшить пустые столбцы, создавая отношения один-к-одному, или же виджет может иметь более одной спецификации веса и доставки?

Это также означает, что вам придется ЛЕВО СОЕДИНИТЬСЯ с обеими вспомогательными таблицами, чтобы проверить информацию, когда для отдельной таблицы не требуется ничего особенного (кроме проверки IS / IS NOT NULL в определенных ситуациях).

Отношения один-к-одному - это оптимизация производительности, но не поэтому вы задаете этот вопрос ...

...