我的任务是重新分解SQLServer数据库....许多表和列“允许NULLS”，这是一个很好的做法......
我似乎记得CSLA.NET的创作时说在数据库中允许空值是非常糟糕的做法......
如果是这种情况，我的替代方案是什么？
从所有列中删除所有“ALLOW NULLS”....在数字列中使用值-1例如??
我真的很感激任何人的任何输入。
我目前正在使用我的数据库中的模型（来自实体框架）和“允许NULLS”的数据库列为空...并且一些存储过程要求我有一个默认值...即BOOLEAN要求默认为FALSE ...但它为null ..
嗯，我不想偏离原来的问题，所以NULLS从我能收集到的东西中是件坏事....所以我该如何解决这个问题呢？
任何帮助真的很感激
答案 0 :(得分：8)
毫无疑问，在可能的情况下应该避免使用NULL，因为它们可能会引入索引和查询语法的几个问题。
由于NULL可能引入的问题，因此一直停止使用它们。然而，像大多数这样的动作一样，它已经失去控制，以至于有些人狂热地坚持不应该在数据库中使用NULL。我在这个营地待了很多年，才发现它有点过分热心。
答案介于两者之间。应尽可能避免使用NULL，但存储确实存在有效的业务原因。
通常你需要存储一个可选的数值，很多人会告诉你只需存储一个零来表示“没有价值”，但这是一个更糟糕的反模式，它存储了一个真正意义上的神奇价值。如果你不能对一个字段使用零，那么因为零被认为是一个有意义的值，或者因为这个值被用作除数的倍数，所以你需要使用一些其他的神奇值（-1？ ）对于这种情况下的那个字段，现在你有一个更糟糕的问题，因为所有可选的数字字段现在表现不同。 OYE。
日期是可空领域的一个更引人注目的候选人。人们在.NET中使用的标准“无值”是默认的未分配DateTime值，即DateTime.MinValue，或更具体地说是0001年1月1日。但是，您无法将此魔术值写入SQL数据库，因为默认的最小值为SQL Server DATETIME字段是1973年1月1日。您现在必须要有一些东西可以检查您在写入和读取数据库时是否正确地翻译这些值，并且您必须在检查的地方进行防御性编码您的日期字段是否小于SqlDateTime.MinValue，只是检查它们是否等于DateTime.MinValue。双Oye。
我倾向于处理真实存在的价值观，而不是建立许多人工构造来隐藏该领域的真实含义和用法。如果某个字段很可能没有值，则使其可为空，并使其在应用程序对象中也可以为空（如果您的语言支持这样的事情）。然后，无论何时使用该字段，都需要考虑在它为NULL的情况下应该做什么，但这实际上是一件好事。一般来说，我反对让开发人员在不必要的代码复杂性上浪费大脑，但这是因为它将重点放在正在解决的真正业务问题上;但是，在这种情况下，缺乏价值是真正的商业问题的一部分，必须加以考虑。如果您只是默认这些值，那么编写公式或算法的开发人员将不太可能考虑缺少值的边缘条件，并且可能甚至没有意识到这些值可能会丢失
答案 1 :(得分：1)
Null有时是一个有效的列值，但我建议更好的做法是改为添加默认值并使列不为空。
如果您要考虑现有数据，则必须执行以下更新：
update TableA set ColumnA = 'default value' where ColumnA is null
...如果你想对现有数据施加'not null'。
如果没有合理的默认值，则null可以是完全有效的列值 - 但通常有一个合适的默认值。
答案 2 :(得分：1)
使用空值是轻微非规范化可以带来巨大性能优势的情况。在现实世界中，NULL值是一种完全有效的方式，表示值没有 记录。这与布尔值（BIT）和可选数值特别相关。
纯粹主义者会让你创建一个带有左连接的新表来记录这个值。现实主义者将改变现有表并添加空值。
肯定存在空值相关的情况。出于完全相同的原因，Nullable泛型被添加到.net框架中以获取值类型。
答案 3 :(得分：-4)
NULL是人类面临的一个障碍，应该从存在中消除。然而不幸的是，当前的系统和语言（尤其是SQL）无法适应当前思维的彻底改革。事实上，SQL是这种歪曲的主要肇事者。
因此，在现实世界中，我给出的建议是尽可能地避免使用NULL，但接受现实，即有时候没有简单的替代方案。