Ненулевые иностранные ключи как стандарт базы данных - PullRequest
2 голосов
/ 19 ноября 2009

История вопроса: сегодня проблема возникла при использовании служб отчетов SQL Server. Похоже, что раскрывающиеся параметры SSRS в средстве просмотра отчетов не позволяют указать (нулевую) опцию, чтобы вы могли видеть отчет, в котором этот параметр равен нулю. По сути, таблица A является таблицей, ссылающейся на таблицу B; так как в отчете для заполнения раскрывающегося списка используется таблица B, в качестве опции нет пустых значений, и поэтому вы не можете выбрать все А, которые имеют нулевое значение B.

Мой настоящий вопрос связан с потенциальной реакцией коленного рефлекса на вышеупомянутую проблему со стороны типа руководства, которому я отвечаю. Когда я объяснил, что происходит, она выдала новый мандат, согласно которому все внешние ключи должны быть ненулевыми, и что в каждом объекте должна быть вставлена ​​запись «по умолчанию», новый стандарт, по-видимому, для решения этой проблемы в инструменте отчетности. По сути, если у вас есть таблица Cat, то Cat.Owner никогда не должен иметь значение null, а вместо этого должен ссылаться на запись по умолчанию в таблице Person, то есть на личность по умолчанию.

Хотя это может помочь в проблеме SSRS, это может повредить разработке / обслуживанию сервисов и приложений, использующих базу данных, поскольку теперь им придется не только учитывать нулевые значения (которые были разрешены до этого момента), но и искать и правильно использовать запись «по умолчанию». Я думал о том, чтобы попытаться отговорить ее от мандата, но я хотел бы получить некоторую информацию от опытного, прежде чем я решу это сделать.

Может ли кто-нибудь взвесить, что это может помочь или навредить?

Кто-нибудь имел это как стандарт базы данных? Любые вопросы, развитие или иное, я должен помнить?

Ответы [ 2 ]

2 голосов
/ 19 ноября 2009

NULL поля означают без значения .

Так что логично и правильно заполнить пропущенное отношение NULL.

Иногда я видел, в некоторых особых случаях, использование записи по умолчанию , как описано в вопросе. Но это был «особый случай» и использовался «иногда».

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

0 голосов
/ 19 ноября 2009

Хотя, если CAT является OWNED_CAT, то он должен иметь ЧЕЛОВЕКА в качестве владельца, если он оставлен, его НЕ должно быть в этой таблице.

Однако, если CAT является ANY_CAT (с / без владельца), то этот брошенный CAT не должен быть связан с каким-либо ЛИЦОМ.

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

Не могу предложить вам много, только мои 2 цента.

...