Необязательные внешние ключи как стандарт базы данных

Question

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

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

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

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

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

Answer 1

NULL поля no value.

Итак, логично и правильно заполнить отсутствующее отношение с помощью NULL.

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

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

Answer 2

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

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

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

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