设计数据库时,数据库中应该绝对不允许空值的存在
来源:互联网 发布:淘宝售中客服工作流程 编辑:程序博客网 时间:2024/05/29 13:57
一句话: 设计数据库时,数据库中应该绝对不允许空值的存在!
下面是两篇精彩文章:
关于数据库空字段和DEFAULT值等问题
http://unruledboy.cnblogs.com/archive/2004/06/27/18988.aspx
刚才看了http://www.cnblogs.com/liukun966123/archive/2004/06/25/18570.aspx?Pending=true中说到空字段的问题,作了回复,感觉意尤未尽,为了确认我的想法,马上查了一下一些数据库设计书籍,其中一本《SQL SERVER 2000从入门到精通》里面提到:
DEFAULT 限制:DEFAULT限制可以对任何表中的列提供缺省值,即新对象的该列没有指定数值时,这个限制会提供缺省值。DEFAULT限制可以对新记录提供合理值,从而帮助实现域完整性。DEFAULT限制还可以帮助实现用户定义完整性:例如,所有新客户可以从账户余额0开始。
其实,我学习数据库并没有上过任何正规的课程,都是从朋友身上学的,可以说是偷师,虽然我平时这样认为,这样设计数据库,不敢妄下结论,所以才找相关书籍印证。
实际上,我们应该保证数据的完整性,字段允许为空是一个下策,只有没有办法的情况下才使用,我建议大家一般都应该不允许为空,并添加缺省值。
毕竟,如果允许字段为空,那把判断为空等问题到带到代码中,如果多个地方判断,那得多写多少代码,而且还得为了应付Null而做额外的容错。
看了“灵感之源”关于数据库空值问题的想法,表示赞同
http://www.cnblogs.com/william_fire/archive/2004/06/27/19046.aspx
个人观点,仅供参考。 设计数据库时,数据库中应该绝对不允许空值的存在!
因为空值在实际的业务模型中,是不允许存在的,因为它没有任何意义,目前的数据库系统都提供了空值的功能,这是经过数学检验的关系数据库本身功能之一,其作用如同指出一个通用的,表示“没有”或“不存在”的意思,但我认为,这是关系型数据库本身思想中,所没有能够充分约束的问题之一。
首先,数据库如果是作为独立的数据表达来看,有空值列,当然可以对外界的信息作出正确的反应,但如果数据库作为与外界交互的,并且内部有独立的业务表达逻辑时,就不应该允许空值列的出现,严格的说,在对于外界的应用程序中,是不允许空值列的出现的,因为这不但要求外界应用程序需要再求一次判断,并且还要求了外界应用程序能针对类似的状况进行处理,很明显地,增加编程的复杂性。
其次,在对象模型中,一个固定的对象有N个固定的属性,一般情况下,根据所有的属性的组合,我们可以寻找到指定的对象,如果对象的属性发生变化,并不影响该对象本身,但如果属性有了增加或减少,就会改变对象的类。
在数据库中的关系映射到Object也是一样,空值属性在某些情况会被认同为该属性并不存在(虽然它会突然又有了,但这应该作为该对象的状态而不是对象出现),这十分不利于关系与Object的映射。
在java中的,有O/R可以对象和关系进行转换,.net中虽然目前没有相应的并很成熟的工具,但我觉得,采取OO的思想仍是必要的,毕竟,对事物的描述是一个复杂的过程,尤其是在开发大型的数据库上,最现实的问题就是,业务逻辑的规则,将严重地影响编程效率。
所以,空值的问题,应该由数据库本身设计时就解决掉,而不应该在应用程序的数据访问层中进行处理。
灵感之源的说法是对的,我表示赞同。并且,无论何种情况下,数据库中,都必须解决空值问题,因为任何存储的数据类型都应该是固定,VB6中的通用变量带来的效率及编程逻辑上的麻烦,相信对VB研究的人都比较明白,这已经不仅仅是一个良好习惯和规范性的问题,更多的是对现实世界的建模问题。
下面是两篇精彩文章:
关于数据库空字段和DEFAULT值等问题
http://unruledboy.cnblogs.com/archive/2004/06/27/18988.aspx
刚才看了http://www.cnblogs.com/liukun966123/archive/2004/06/25/18570.aspx?Pending=true中说到空字段的问题,作了回复,感觉意尤未尽,为了确认我的想法,马上查了一下一些数据库设计书籍,其中一本《SQL SERVER 2000从入门到精通》里面提到:
DEFAULT 限制:DEFAULT限制可以对任何表中的列提供缺省值,即新对象的该列没有指定数值时,这个限制会提供缺省值。DEFAULT限制可以对新记录提供合理值,从而帮助实现域完整性。DEFAULT限制还可以帮助实现用户定义完整性:例如,所有新客户可以从账户余额0开始。
其实,我学习数据库并没有上过任何正规的课程,都是从朋友身上学的,可以说是偷师,虽然我平时这样认为,这样设计数据库,不敢妄下结论,所以才找相关书籍印证。
实际上,我们应该保证数据的完整性,字段允许为空是一个下策,只有没有办法的情况下才使用,我建议大家一般都应该不允许为空,并添加缺省值。
毕竟,如果允许字段为空,那把判断为空等问题到带到代码中,如果多个地方判断,那得多写多少代码,而且还得为了应付Null而做额外的容错。
看了“灵感之源”关于数据库空值问题的想法,表示赞同
http://www.cnblogs.com/william_fire/archive/2004/06/27/19046.aspx
个人观点,仅供参考。 设计数据库时,数据库中应该绝对不允许空值的存在!
因为空值在实际的业务模型中,是不允许存在的,因为它没有任何意义,目前的数据库系统都提供了空值的功能,这是经过数学检验的关系数据库本身功能之一,其作用如同指出一个通用的,表示“没有”或“不存在”的意思,但我认为,这是关系型数据库本身思想中,所没有能够充分约束的问题之一。
首先,数据库如果是作为独立的数据表达来看,有空值列,当然可以对外界的信息作出正确的反应,但如果数据库作为与外界交互的,并且内部有独立的业务表达逻辑时,就不应该允许空值列的出现,严格的说,在对于外界的应用程序中,是不允许空值列的出现的,因为这不但要求外界应用程序需要再求一次判断,并且还要求了外界应用程序能针对类似的状况进行处理,很明显地,增加编程的复杂性。
其次,在对象模型中,一个固定的对象有N个固定的属性,一般情况下,根据所有的属性的组合,我们可以寻找到指定的对象,如果对象的属性发生变化,并不影响该对象本身,但如果属性有了增加或减少,就会改变对象的类。
在数据库中的关系映射到Object也是一样,空值属性在某些情况会被认同为该属性并不存在(虽然它会突然又有了,但这应该作为该对象的状态而不是对象出现),这十分不利于关系与Object的映射。
在java中的,有O/R可以对象和关系进行转换,.net中虽然目前没有相应的并很成熟的工具,但我觉得,采取OO的思想仍是必要的,毕竟,对事物的描述是一个复杂的过程,尤其是在开发大型的数据库上,最现实的问题就是,业务逻辑的规则,将严重地影响编程效率。
所以,空值的问题,应该由数据库本身设计时就解决掉,而不应该在应用程序的数据访问层中进行处理。
灵感之源的说法是对的,我表示赞同。并且,无论何种情况下,数据库中,都必须解决空值问题,因为任何存储的数据类型都应该是固定,VB6中的通用变量带来的效率及编程逻辑上的麻烦,相信对VB研究的人都比较明白,这已经不仅仅是一个良好习惯和规范性的问题,更多的是对现实世界的建模问题。
原文地址 http://unruledboy.cnblogs.com/archive/2004/06/27/18988.aspx
- 设计数据库时,数据库中应该绝对不允许空值的存在
- 数据库设计中应该注意的问题
- 数据库设计中,日期字段的类型应该如何选择?
- 金额如果存在数据库中应该使用何种类型?
- 设计数据库的表时应该考虑的因素
- [数据库]关于设计表时应该注意的问题
- oracle数据库对date字段类型存在空值进行排序的处理方法
- 数据库不允许为空默认值为0,实体类的配置
- 移动数据库中存在的图片
- 数据库字段中存在单引号的处理
- Oracle数据库中数字与空值的排序问题
- C#中往数据库插入空值的问题
- 关于Oracle数据库中SQL空值排序的问题
- 关于Oracle数据库中SQL空值排序的问题
- 关于Oracle数据库中SQL空值排序的问题
- 数据库设计应该注意什么?
- 在sql数据库的表设计中,其中有一栏是允许空是什么意思?
- 向数据库中存储空值
- 批量更新数据引起 DataGrid 的绘制错误及解决方法
- 关于使用Asp.net导出Excel,遭遇“LinkButton必须放在一个具有runat=server的标签的Form”的解决方案。
- TCP端口号对照表
- 创建HttpRequest对象
- Linux 进程管理
- 设计数据库时,数据库中应该绝对不允许空值的存在
- 艾瑞网·中国新经济门户 - http://www.iresearch.cn
- C语言-time.h从头学
- 道琼斯新闻集团达成初步协议 每股60美元收购
- Windows API一日一练(4)MessageBox函数
- .,l
- toString()的使用
- 什么是cmm3规范?什么是CMMI5 呢?
- 关于函数可重入性