Помогите понять БД Схема / Дизайн

Question

Здравствуйте, я сталкиваюсь со следующим ...

Две таблицы БД (таблицы MySQL MySQL - без ограничений внешнего ключа) 'MASTER' и 'CHILD'.Строки в таблице базы данных 'CHILD' ссылаются на одну строку (1: M) в таблице 'MASTER', используя parent_id * столбец *.

Проблема заключается вчто столбец parent_id имеет 2 «типа» значений:

• Значение NON-ZERO, ссылающееся на строку в таблице 'MASTER'
• Значение ZERO, означающее, что строка не являетсяссылаясь на таблицу «MASTER».В этом случае строки со значениями ZERO в столбце parent_id «фактически означают» что-то другое => представляют данные другого типа (хранящиеся в одной таблице? Т.е. хранящие яблоки и апельсины в одной таблице, когда эти два лучше всего хранить вдругая таблица)

Я в замешательстве.Это просто плохой дизайн базы данных?Общепринятая практика - различать «что представляют собой строки в таблице БД», используя разные значения в столбце, который используется для ссылки на «родительские строки» в другой таблице.

Если вы не растерялись и можете помочь, пожалуйста,делать:)

Answer 1

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

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

Это плохая идея с точки зрения создания кода без ошибок, потому что, если вы забудете отсеять строки, которые не относятся, вы получите неправильные результаты.

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

Это плохой дизайн.

Сказав это, есть необязательный FKполя в хорошо разработанных базах данных.В таких случаях строки, отказывающиеся от отношения, содержат NULL, а не ноль в ячейке.Однако даже в таких случаях на семантику остальных столбцов не влияет наличие или отсутствие взаимосвязи.

Answer 2

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

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

Это не хороший дизайн - база данных должна отвечать за свою целостность.

Answer 3

У меня недостаточно информации, чтобы сказать, плохой дизайн или нет.

Для меня это звучит как стандартные отношения один ко многим.

Вас огорчают два разных значения в столбце CHILD, который ссылается на MASTER. Это звучит как обычный способ представления для меня обнуляемого внешнего ключа. Это говорит о том, что вы можете иметь строку CHILD, которая не принадлежит ни одной строке MASTER. В качестве примера можно привести базу данных для школы, которая присваивает одну или несколько строк STUDENT строке SCHOOL.

Ссылка из таблицы STUDENT может быть нулевой; в конце концов, мы не убиваем / не удаляем STUDENT, кто не назначен в школу, не так ли?

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

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

ОБНОВЛЕНИЕ: я могу вспомнить одну историческую причину, которая могла бы объяснить это.

Более старые версии MySQL не обеспечивали ссылочную целостность, пока не появился механизм ISAM. Возможно, ваша схема была разработана до ISAM, поэтому разработчики решили, что им придется самостоятельно управлять ссылочной целостностью. Если вы обновились до ISAM, возможно, схема не была перенесена вместе с ней.

Пожалуйста, игнорируйте эту идею, если мои предположения об истории неверны.

Answer 4

Это очень плохой дизайн.Вам нужна третья таблица linking или join , которая имеет два столбца: идентификатор вашей так называемой дочерней таблицы и идентификатор в основной таблице.В этой таблице будет запись для каждой строки в вашей дочерней таблице, которая в настоящее время имеет ненулевой родительский идентификатор.

Обновление: возможно, «очень плохо» - это оператор over, так как вы можете использовать nullableвнешний ключ, как другие заявили, но он должен зависеть от частоты нулей.Если большинство строк имеют ненулевую ссылку на мастер, чем идти с обнуляемым FK, в противном случае используйте таблицу ссылок.