一句话: 设计数据库时，数据库中应该绝对不允许空值的存在！

下面是两篇精彩文章:

关于数据库空字段和DEFAULT值等问题


刚才看了中说到空字段的问题，作了回复，感觉意尤未尽，为了确认我的想法，马上查了一下一些数据库设计书籍，其中一本《SQL SERVER 2000从入门到精通》里面提到：

DEFAULT 限制：DEFAULT限制可以对任何表中的列提供缺省值，即新对象的该列没有指定数值时，这个限制会提供缺省值。DEFAULT限制可以对新记录提供合理值，从而帮助实现域完整性。DEFAULT限制还可以帮助实现用户定义完整性：例如，所有新客户可以从账户余额0开始。

其实，我学习数据库并没有上过任何正规的课程，都是从朋友身上学的，可以说是偷师，虽然我平时这样认为，这样设计数据库，不敢妄下结论，所以才找相关书籍印证。

实际上，我们应该保证数据的完整性，字段允许为空是一个下策，只有没有办法的情况下才使用，我建议大家一般都应该不允许为空，并添加缺省值。

毕竟，如果允许字段为空，那把判断为空等问题到带到代码中，如果多个地方判断，那得多写多少代码，而且还得为了应付Null而做额外的容错。


看了“灵感之源”关于数据库空值问题的想法，表示赞同



个人观点，仅供参考。 设计数据库时，数据库中应该绝对不允许空值的存在！

　　因为空值在实际的业务模型中，是不允许存在的，因为它没有任何意义，目前的数据库系统都提供了空值的功能，这是经过数学检验的关系数据库本身功能之一，其作用如同指出一个通用的，表示“没有”或“不存在”的意思，但我认为，这是关系型数据库本身思想中，所没有能够充分约束的问题之一。

　　首先，数据库如果是作为独立的数据表达来看，有空值列，当然可以对外界的信息作出正确的反应，但如果数据库作为与外界交互的，并且内部有独立的业务表达逻辑时，就不应该允许空值列的出现，严格的说，在对于外界的应用程序中，是不允许空值列的出现的，因为这不但要求外界应用程序需要再求一次判断，并且还要求了外界应用程序能针对类似的状况进行处理，很明显地，增加编程的复杂性。

　　其次，在对象模型中，一个固定的对象有N个固定的属性，一般情况下，根据所有的属性的组合，我们可以寻找到指定的对象，如果对象的属性发生变化，并不影响该对象本身，但如果属性有了增加或减少，就会改变对象的类。

   在数据库中的关系映射到Object也是一样，空值属性在某些情况会被认同为该属性并不存在（虽然它会突然又有了，但这应该作为该对象的状态而不是对象出现），这十分不利于关系与Object的映射。

　　在java中的，有O/R可以对象和关系进行转换，.net中虽然目前没有相应的并很成熟的工具，但我觉得，采取OO的思想仍是必要的，毕竟，对事物的描述是一个复杂的过程，尤其是在开发大型的数据库上，最现实的问题就是，业务逻辑的规则，将严重地影响编程效率。

　　所以，空值的问题，应该由数据库本身设计时就解决掉，而不应该在应用程序的数据访问层中进行处理。

　　灵感之源的说法是对的，我表示赞同。并且，无论何种情况下，数据库中，都必须解决空值问题，因为任何存储的数据类型都应该是固定，VB6中的通用变量带来的效率及编程逻辑上的麻烦，相信对VB研究的人都比较明白，这已经不仅仅是一个良好习惯和规范性的问题，更多的是对现实世界的建模问题。