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

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

　　因为空值在实际的业务模型中，是不允许存在的，因为它没有任何意义，目前的数据库系统都提供了空值的功能，这是经过数学检验的关系数据库本身功能之一，其作用如同指出一个通用的，表示“没有”或“不存在”的意思，但我认为，这是关系型数据库本身思想中，所没有能够充分约束的问题之一。
　　首先，数据库如果是作为独立的数据表达来看，有空值列，当然可以对外界的信息作出正确的反应，但如果数据库作为与外界交互的，并且内部有独立的业务表达逻辑时，就不应该允许空值列的出现，严格的说，在对于外界的应用程序中，是不允许空值列的出现的，因为这不但要求外界应用程序需要再求一次判断，并且还要求了外界应用程序能针对类似的状况进行处理，很明显地，增加编程的复杂性。
　　其次，在对象模型中，一个固定的对象有N个固定的属性，一般情况下，根据所有的属性的组合，我们可以寻找到指定的对象，如果对象的属性发生变化，并不影响该对象本身，但如果属性有了增加或减少，就会改变对象的类。
在数据库中的关系映射到Object也是一样，空值属性在某些情况会被认同为该属性并不存在（虽然它会突然又有了，但这应该作为该对象的状态而不是对象出现），这十分不利于关系与Object的映射，
　　在java中的，有O/R可以对象和关系进行转换，.net中虽然目前没有相应的并很成熟的工具，但我觉得，采取OO的思想仍是必要的，毕竟，对事物的描述是一个复杂的过程，尤其是在开发大型的数据库上，最现实的问题就是，业务逻辑的规则，将严重地影响编程效率。

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

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