一个很值得探讨的数据库问题,200个大洋!!(200分)

  • 主题发起人 主题发起人 dbclient
  • 开始时间 开始时间
D

dbclient

Unregistered / Unconfirmed
GUEST, unregistred user!
对于数据库的设计,少不了三范式,而按照三范式设计出来的数据库应该是比较紧凑、简练的,但是在对三范式数据库操作的过程中,表关联比较多,这样会降低数据库运行速度,为了提高运行速度,我们常常允许一些数据冗余,通过牺牲空间来提高数据库的速度。但是数据冗余过多是绝对不行的,不知道各位大虾对这个问题有什么看法,有没有好的办法来协调数据冗余与速度,或者说把数据冗余控制在一个怎样的程度内,以设计出性能比较好的数据库结构来。
 
其实作为一个标准的程序员在设计数据库的时候,应该达到第三范式,而数据库表关联较多,在现在的数据库版本,应该不会有太大影响;
其实不但但是以上条件所限,其实数据库服务器的性能也占一定比率.
 
我的做法是
1、当速度是平颈时,牺牲空间换速度,
2、否则,按第3范式来。
 
我的作法是:对使用率高的库加入冗余数据(如某些累计字段)。

 
在实际编程中肯定是要变通的,不可能完全按三范式来实现。不然有的统计操作会非常难以实现。
 
同意 tanglu 如你的数据要作报表时无冗余字段会很慢,数据库允许使用冗余技术
提高速度
表的关联多
一是速度慢,它也并没带来太多的好处(比如:数据库的提示信息是英文等)
相同的地方可用程序自己实现.
 
看 Delphi Demo中的 MasterApp 就知道了,他的 Orders 表中其实就有冗余:
该单子的合计金额,可以自动算出来,但还是存起来了,就是为了速度。
在两者之间找个平衡点吧,常用的表,如果其中有哪个字段是计算字段或查询字段,
可以考虑设为冗余字段,一般的小表就没必要了。
 
大家不知道有没有试过用多线程去解决比如查询和浏览这样的独立的事件
 
如果严格按第三范式来,在某些时候,效率是会降低的。
允许一些冗余是必要的,不过你要考虑冗余带来的数据量有多大的问题,事先做一个
估计,然后在做决定。
 
据我所知,真正严格按第三范式设计的数据库系统少。
第二范式能完全满足都难。
但我一般还是尽力而为,一些汇总的,一些计算的字段,还是不放在基表中的。
一些冗余能明显提高效率的还是冗余的好。没有一个划一的标准,因系统不同而异。
 
1、采用二维表的三维用法来降低数据分散性。
2、参考中国的户籍管理方法来控制数据。
3、采用容器法则来使数据可视化。
4、参考一下4NF标准。
5、学好SQL语句。
 
可以考虑将经常同时使用的数据段放在同一数据表内。根据应用的具体需要确定冗余量。
 
用户是上帝,上帝要你快你能慢吗?
 
多人接受答案了。
 
后退
顶部