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

Question

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

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

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

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

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

Answer 1

НУЛЕВЫЕ поля означают никакой ценности.

Так что логично и правильно заполнять недостающее отношение нулями.

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

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

Answer 2

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

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

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

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