Как уже упоминалось, ввод данных на передней панели должен позволять пропуск многих полей. Это усложняется тем, как люди интерпретируют тринарную природу NULL (например, пустая или отсутствующая).
Поэтому я отвечаю только об одном аспекте проектирования базы данных: внешних ключах.
В общем внешние ключи не страдают от произвольного характера бизнес-логики, поэтому, видя, что эти столбцы, допускающие NULL, являются определенно запахом кода.
Например, если бы у вас была таблица [Person], ни в одной ситуации вы бы никогда не имели значение [Person].[FatherID], которое было бы NULL преднамеренно .
Для большой базы данных попытка сохранить NULL в таком столбце, вероятно, произойдет в какой-то момент из-за неизбежности ошибок, которые были бы обнаружены намного раньше при наличии ограничения NOT NULL. Поэтому для версии 1 или таблицы никогда не следует разрешать пустые столбцы без объяснения .
Но в развивающейся базе кода дела обстоят гораздо сложнее, особенно в том, что он остается в сети и, следовательно, требует обновления сценариев миграции для обновления. В частности, позже вы можете найти пустые столбцы, добавленные в таблицы, потому что правильное добавление их как необнуляемых может быть довольно сложным в зависимости от процесса интеграции.
Кроме того, разработчики визуальных таблиц (например, в SQL Server Management Studio и Visual Studio) по умолчанию разрешают NULL, так что это может быть просто вопросом неадекватного просмотра кода.
Я не хочу пытаться получить правильный ответ для флаговых (т. Е. Логических) столбцов, но я настоятельно рекомендую рассмотреть вопрос о том, как их можно реализовать, не допуская NULL, поскольку я обычно находил способы избежать обнуляемости даже в условиях бизнес-логики.