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


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

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

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

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

  • 相关阅读:
    将n个不同的球放到m个相同的袋子里有多少种方案?

    平面分割直线2
    差分
    并查集(UnionFind)
    约瑟夫环公式
    Kruskal
    线性欧拉筛
    SPAF
    Dijkstra
  • 原文地址:https://www.cnblogs.com/William_Fire/p/19046.html
Copyright © 2020-2023  润新知