对关系数据库的怀疑(100)

  • 主题发起人 主题发起人 我爱PASCAL
  • 开始时间 开始时间
我

我爱PASCAL

Unregistered / Unconfirmed
GUEST, unregistred user!
我对关系数据库产生了怀疑，这么多年来，阻碍程序员发展的就是这个关系数据库。现在越来越觉得关系数据库就是一个制约人的东西。它说得很好，减少数据贮存的容余，可是呢，当你查询时，它就需要花大量时间用于匹配。最关键的是，它说表的字段不能太多，这实在是不能体现二维数据的优越性。请问有没有一种更好的方式来代替关系数据库？
 
面向對象的數據庫！！！！！！其實，關係數據庫還是比較方便的，雖然有不少的限制，而且感覺如果完全按照一些模式去做會很麻煩，但還是比較靈活的，用起來還好了，尤其是對oracle來說，比sql server多了不少的功能，可以減少開發人員的工作量。關係數據庫最大的成功就是拉動了服務器的發展，配置越來越高了！！！
 
对啊，过去我就迷信第三范式，第四范式。现在发现那些就是忽悠人的东西。范式高了，随便查个什么都要用很多的连结，系统内存销耗很大。这个是第一，最关键的是现实世界并不是这样。比如一个经理管理一个片区，一个片区下有N个城市，一个城市有N个客户，一个客户有N个订单，一个订单有N个货。这个按关系数据库来处理就必定只把经理和片区建一个关系，也就是放在一张表中。到是一个查询就能查到一个月内这个经理卖了某个货多少销售量。初一看好象很科学。其实问题很多：如果在一个月内这个经理换成另一个经理那就乱套了。或是一个客户搬家到另一个地方也完了。总之问题很多。
 
当然了，你可以说，那我们把经理，片区和日期也建立关系。进而把客户和城市和日期也建立关系。总之要完全维护范式，就会建很多很多的关系。查询就会搞得越来越复杂，SQL越写越长，连结时间越来越长，内存越用越大。我的做法是，在订单中添加货时就加上经理的大名，这样虽在占空间，但不怕以后乱套。以后如果换经理，但过去的订单已发生，是不能改变的。是谁卖出的就是谁的，更准确可靠，查询很简单。一个GROUP BY就可以查出。其实上面的关系如不是一月内换经理，就是不同月换了经理，不加月分的关系一样会出错。
 
不同类型的数据要区别对待，流水帐这些数据不必遵守三个范式。
 
当年我写的一个程序，为了一种效果，将十多个表连接了几十次，才得出结果，那速度是相当的慢啊，查询一次要几分钟。
 
主流数据库都是关系数据库吧。80%-90%的自然关系都适合的，10%-20%可以将就表示。换别的，用得人少，开发成本都收不回来。
 
>>当年我写的一个程序，为了一种效果，将十多个表连接了几十次，才得出结果，那速度是相当的慢啊，查询一次要几分钟。 这就是关系数据库的问题，所在，既然最终还是要连结，不如早就在需要的地方留下字段，虽然容余，但更新时可以用触发器更新它。关系数据库确实能表述一切，但是不一定就是效率最高的，比如网格的地图：关系数据库就需要表述为：X，Y，图标这样如果地图很大的话，就需要用索引来读入，而且很慢。如果采用二维数组的话，要调入地图的一部分就非常快，顺序读入就是了。纵横无限的二维表是很好的方式，可是关系数据库确反对这样。它非要表示成效率极低的关系。
 
不是数据库或工具不好，是程序员的水平不够高，如果不是靠程序来提高效率，那程序员写的程序有什么作用！
 
不要把关系数据库说的一无是处，其实他还是挺有贡献的。 当然任何一种模式都不可能放之四海而兼准，在适当的时候，还是要变通使用的，“尽信书不如无书”嘛。
 
那楼上你怎么不用486电脑编程？我现在说的是关系数据库本身的问题，而不是它内部的查询优化。真要玩优化的话，我也不是不会，我对优化代码提高速度这些是比较在意的。正因为对效率和技术革新的原因，我才对关系数据库本身提出疑问。
 
占楼了，“楼上”不是说的levi,是更上面一楼。贡献当然是有，只是说不要过于迷信，认为这就是存数据的唯一和标准和主流方法。特别是N范式理论。当关系数据库出来前，不是同样有人像你这么说：“不要把层次数据库说的一无是处，其实他还是挺有贡献的。”也许会出现一种更好的数据组织方式来代替这个东西。和“贡献”来比，我想它对程序员的束缚更严重。
 
它的有些奉为原则的东西，我觉得可以打破一下，但是不幸的是这些原则影响了数据库工具软件。比如说它不准动态增减字段。说为一个表设很多字段是不科学的做法。于是很多数据库限制字段数为256以下或1024以下。并说字段设得越少数据库就设计得越高明，并嘲笑那些设了很多字段的表的程序员。它鼓吹多设表，也不多设字段。比如一个货物有多个库房，在每个库房里有个库存量。这个就是进销存的多库房功能。一个“不合格”程序员是这样设计的：货物号 库存1 库存2 库存3 库存4 库存5 库存6 库存7 ...库存N 一个“资深”程序员是这样设计的：货物号 库房号 库存量我想很多高手都会认为第二个设计得科学，可扩展性强。其实我认为一点也不强，这只是关系数据库本身的缺陷使它无法设计成第一种情况而已。如果打印到纸上，一个普通库管员一定会认为第一种表设计得很好，很直观。认为第二个表很喜剧。有的说，那我可能通过查询得到第一表的样子。好吧。那请SQL高手写来看看呢。
 
不能因为自己手上有把锤子，就把所有其他东西看成是钉子。就象前面说的地图数据，你看Oracle，有把它存成关系数据库吗
 
多人接受答案了。
 
分错了,应该给zbdzjx分五十分
 
您必须登录或注册才可回复。

Similar threads

Ray
[转]终于可以发布Delphi下收点OSGI精髓皮毛而设计的插件框架WisdomPluginFramework
回复
4
查看
4K
chlkuei
C
G
关于PARADOX数据库的问题(200分)
回复
12
查看
216
goujie
G
山
求救！！我用delphi的bde引擎链接access数据库处理更新数据，速度奇慢啊！！！高分，高分！(200分)
回复
10
查看
164
山水之间
山
山
数据库表如何释放内存？(100分)
回复
14
查看
263
山水之间
山
青
急，如何压缩数据Access数据库。(10分)
回复
15
查看
221
青云
青
后退
顶部