数据库的设计几乎决定一个项目的成败！

yh2ygy

根本不可能在设计阶段把所有的问题都考虑清楚
1。时间一般不允许
2。实际应用往往很复杂，简单的应用不会出问题，出问题也没有太大影响
3。我认为，正确的思路应该是在设计的时候考虑到将来更改设计的方便方法
我们可以抓住的是设计本身，记住不能在这个时候过多考虑将来业务如何变更
因为业务的变更往往是没有规律的，如果只考虑将来业务会如何如何变化，
等于是白费苦心。精巧的设计应该是对于很多业务领域都可以适应的

yjsok

请问斑竹有没有学习ORCAL的相关电子文档和E_BOOK,非常感谢。
或学习课件。
谢谢

Z ZG
FROM ZHUHAI
66979298

jim1248

我觉得设计数据库绝对不可以照本宣科，而是应该根据实际情况，编码的方便性，已经数据库的读取次数等来综合考虑。虽然设计的数据库如果满足3范式可以很精简，没有什么冗余，但是有时候适当的把常用的数据做些冗余的设计，对编码以及数据库的效率都会有大大的提高

心在流泪

最初由 neverbcool 发布
[B]对需求变化要有一定的预估！

另外，在设计阶段最容易犯的毛病就是只考虑IF的情况，而在实际运作中往往是ELSE…… [/B]

你说很对，，跟数据库的设计没多大关系，数据库的设计只是其中一个模块而已。而且还是不很重要的一个模块。系统的“松”不是靠的数据库，而是程序。。。

comput

最初由 sameway 发布
[B]干了这么多年的设计开发，我觉得有些东西大家不能叫书本迷惑住了，就说那三大数据库三大范式，害死不少人，还有那些工具，都是按照标准作的，但是真正作项目是不可能，关键看设计者的经验，这一点，很多数据库大师都有过论述，至于DBA做数据库设计，我觉得不可能作的的很深，因为他没时间去对业务进行研究。再这只是抛砖引玉，不对之处请大家指正。
另请斑竹酌情加分，50篇帖子太多了。 [/B]

一般公司的DBA都不做数据库设计的，一般是由技术总监或者项目经理来做数据库设计。曾经听一个大师说过，数据库设计很容易入门，但是至少三年经验才算真正入门，感受深刻啊。
并且即使有10年数据库丰富经验的大事，除非他专注于某个领域，
否则也很难一次就设计出恰到好处的数据库。（完美的数据库是不存在的，既然是设计本身就是做选择）

在我的思想观念里面。如果按照RUP的软件开发过程，数据库的设计应该是在类图之后的，如果分析设计做得好这个时候应该是对业务了解70%左右，再考虑数据结构的扩展性、一般性和通用性原则，应该可以得到一个较好的数据结构。

weilin_china

最初由 neverbcool 发布
[B]对于一个项目而言，没有什么比过程更重要的了！

开发组织的PROCESS直接决定了项目的成败。
对呀，你有可能会遇到一个糟糕的设计人员，但是组织的SQA小组干什么去了，为什么不进行必须的技术评审？

不要说是一个糟糕的设计人员在不受任何约束的情况下所干的蠢事了，就是一个优秀的设计人员在不受约束的情况下也完全可能会犯下致命的错误！

我不得不说一句可能会招来大量臭鸡蛋或烂西红柿的话：程序员（包括分析师）只有在沦落为流水线上的一个小小环节的情况下，整个生产线的产出质量才回得到保证！

数据库设计当然很重要，但是从工程的角度出发，数据库设计仅仅是整个系统设计的一个部分而已。 [/B]

同意

goldpeak

合理的数据库结构是很重要，不过，大家还忽略了另外一个问题，就是对数据访问的SQL语句的效率。好的SQL语句能很快得到结果。我以前做过一个项目，发现对一个大表（几百万条记录）查询特别慢，差不多要半个多小时，后来经过新家坡的同事调整了以后只要5分钟就出来结果。所以，数据库应用，不但要有好的数据库结构，数据库访问的方式，方法，及SQL语句都很重要。在你不能够修改数据库结构的时候，你也可以在访问的SQl语句上下点功夫。也许可以收到效果

suckdog

都说得好，都有道理。。但是。。。能不能给个主题是大家一起实干的呢？能
真正得到锻炼还是得落实到行动上。请斑竹带头开个TOPIC给大家一起“开发”吧！

luguanhua

[quoto]
最初由 neverbcool 发布
对于一个项目而言，没有什么比过程更重要的了！

开发组织的PROCESS直接决定了项目的成败。
对呀，你有可能会遇到一个糟糕的设计人员，但是组织的SQA小组干什么去了，为什么不进行必须的技术评审？

不要说是一个糟糕的设计人员在不受任何约束的情况下所干的蠢事了，就是一个优秀的设计人员在不受约束的情况下也完全可能会犯下致命的错误！

我不得不说一句可能会招来大量臭鸡蛋或烂西红柿的话：程序员（包括分析师）只有在沦落为流水线上的一个小小环节的情况下，整个生产线的产出质量才回得到保证！

数据库设计当然很重要，但是从工程的角度出发，数据库设计仅仅是整个系统设计的一个部分而已。
[/quoto]
把握用户的需求理所当然的是项目成功的前提（这应该是No.1），PROCESS是项目实施成功的保障。某个环节出问题都有可能导致项目的失败，但用户需求搞错了必然导致项目的失败！

luguanhua

数据库的设计当然极其重要，毫无疑问应该尽量保证3CNF，但有时为了效率需要进行反泛式的设计，简单就是美！
3CNF由数据库管理系统自动保证了业务数据的稳定和一致，而一旦违反，必须靠应用保证。所以反泛式带来编程方便的同时，也必须考虑保证数据一致问题（需要代码保证和进行更多的测试），根据实际情况做一个选择吧！
当系统性能需要保证时，很多时候必须反泛式，毕竟太多的join操作是常见的性能问题之一。