把数据库扔在一边！(请直接下载我最后回复中的详细文档和源代码吧)
恐怕我认识的95％的搞软件的人，在开发一个项目的时候，都会费好大力气去做一个叫做“数据库”文档的东西。
里面使用了大量的表格，文字，等等，告诉用户：你看，我已经把系统的50％设计出来了！
可是，这真的是正确的吗？如果是正确的，为什么我发现90％的情况，这个文档竟然没有被同步更新？或者直到
项目 release 阶段，才会去最后更新一次这个文档？
我终于发现了答案：项目的设计阶段，把数据库扔在一边！
到今天我们已经达到一个共识，就是数据库的操作，其实就是数据持久的操作。什么是持久？就是把一个类里需要
的数据保存到磁盘上。你可以保存到文件里，可以保存到数据库里，这都是持久。
既然如此，那我们为什么还那么着急的确定数据库是什么样子？
我们只要设计出正确类，这个类能存储我们的数据就可以了！至于如何把这个类保存到磁盘上，或者如何从磁盘上
把这个类载入到内存里，那是另一个问题了。
很多人以为这是一个大问题，事实证明，只要你的类图设计的正确，那么持久层的处理与整个系统相比，实在是一件
小事情。而且在设计阶段不去考虑数据库因素，更有助于我们清晰的根据业务来设计系统。
那么有的人又说了，那我如何做单元测试，我可是 TDD 的！
我想，正是 TDD 导致了“把数据库扔在一边”的思维方式。你完全可以把数据库的操作做成一个接口，在单元测试的
时候，使用 mock 的方式。因为在实现业务的阶段，我们只考虑我们设计的类是不是能正确地保存数据，而不在乎它
到底是怎么保存到磁盘上的。
直到你确信业务逻辑正确，那么就可以去实现那个数据库操作的接口，去做真正的持久层。当然，这个名词叫facade模式。
而持久层是使用 hibernate，还是 ibatis ，那是另外一个问题了。如果你一定要说如果在业务逻辑里也有持久层的操作怎么
办，那我只能说你的业务逻辑类设计失败了！
不要在设计初期就费尽脑汁弄数据库设计了，把系统的类图设计正确，数据库也就是持久层的操作自然水到渠成了。
另外，有人可能会说，你这套在java里或许挺有价值，但是Rails呢？ Agile dev with Rails 的作者可是一开始就设计了
数据库的草图。那是因为Rails的持久层实在是太容易了！Rails 里的model，其实就是业务逻辑的model，在设计的阶段，
你设计出了保存数据的类，那么这个类就可以作为model而存在，而针对这个model的逻辑就可以写在这里。
Agile dev with Rails 的作者虽然给我们画了数据库的草图，但我仍然认为他是从模型的角度去考虑问题，而不是从数据库
的角度考虑的。
评论
平时设计就是一会设计数据库表结构，一会研究类图。 改着改着差不多了就开始做，做着不顺了再改设计。然后项目就完工了。
数据库的设计为什么要先行？其目的还是在于和客户的沟通。你可以把数据库当作是需求分析的一部分。你把数据库的设计文档给用户看，其目的就是为了验证你做的东西是否与客户的需求有偏差。
我个人认为，一个完整的数据库是一个项目成功的良好基础。虽然数据库会经常变化，但绝大多数都是细微变化。而且我们可以请客户来review这些变化。
这就好像 Bob 大叔说过的一个例子，他们曾经发起过一个模型设计，
例子就是电灯的开关，结果有的人竟然设计出了电线这个对象。
如果本身就是对开关进行设计，为什么不可以有电线这个对象？
开关里面没有电线么？哦，你说的可能是普通的单刀单掷开关。。。。
电线的绝缘层厚度、耐压参数、阻燃特性
金属芯直径、材质、最高电流
大概的概念，例如订单，商品，用户等等。然后根据直觉或者经验来设计
出数据库。注意，这个过程其实就是先分析业务的过程，只不过是模糊的
分析，在设计完数据库后，然后反过来再看业务如何能按照数据库的设计走，发现走不下去了，再去修改数据库。如此反复。
既然需要如此反复，为什么不先把数据库放一边，把业务层弄明白呢？？
为什么头脑中只是有个大概的概念？业务不熟啊！当然像你说的订单这样的业务，我相信这里绝大部分人都能看明白，完全可以按照你所说的做。
你可能又问把业务层弄明白呢？？说的轻巧！小系统你可以说先把业务弄明白，像银行电信之类的系统等你全弄明白之后，可能业务需求早就变了！大型系统往往是螺旋，渐进，增量式开发，先有鸡还是先有蛋可能早就分不清了。
如果忽视DB，纯粹建立在OO上的空中楼阁是会很容易倒掉的。
本人用了不少的ORM，最后发现还是SQL管用。
我太同意这位同学了，花花肠子搞多了，发现直截了当才真的很爽。
况且管他什么数据库为中心还是什么DDD的，关键是要解决业务，业务需求。
你去给客户说，我的系统采用了宇宙无敌开发法，具有你能想到的所有功能，可以胜任任何情况的变化。对方一定会买你的帐么。
起因是那个系统数据库设计得实在太烂，范式基本不满足，也不符合OOP，本人建议，更换！
其实不论是对象建模还是数据建模，最终的成果都差不多。大家不信可以让同样老道的DBA和UML分析员，分别对同一系统建模，最后是相差不多的，所谓“英雄所见略同”说得就是这回事。原因在于DBA同样要考虑数据的结构合不合理，而UML分析员最后也要考虑效率高不高，最后的折衷结果大体相似。
本人因历史原因，一开始做了很多的数据建模。眼下虽然也OOP、ORM，但UML用的不熟，故基本上还是选择顺手的数据库建模，好在与OOP结合得还算不错。所以习惯数据库建模的老同道们大可不必担心。
多点废话，个人体会数据库建模更简单、直接。如果各位同道经过尝试仍不习惯UML建模（像本人），那么数据库建模又有何妨？
如果忽视DB，纯粹建立在OO上的空中楼阁是会很容易倒掉的。
本人用了不少的ORM，最后发现还是SQL管用。
这话我严重同意。
经常发现在一个系统上线后几年，没人管程序怎么样，多数都是问如何把数据库里的数据提取出来。最后，系统技术文档中的类图什么的都是摆设--大家宁可看源代码，而数据库的模型反而成了最主要的东西了--大家都要这个文档。
b理解为观点1.2，反驳a，祭出观点2.1，
c理解a的为观点1.3，同意a，反驳b，提出的是1.4，
d来掺合，宣传他的观点3.1，
e出来说话，ab各打50大板，提倡大家和谐社会，
……鸡同鸭讲[无恶意的广东方言]怎一个乱字了得~。
鄙视自己一下，8页回帖全看完，真是闲的。
数据库的重要性谁也抹杀不了，对于客户来说，数据才是最重要的。
如果忽视DB，纯粹建立在OO上的空中楼阁是会很容易倒掉的。
本人用了不少的ORM，最后发现还是SQL管用。
优先把功能设计好，数据库和算法是功能设计的衍生
- 浏览: 135184 次
- 详细资料
搜索本博客
我的相册
共 3 张
最新评论
-
TDD，想说爱你不容易
stevenwang 写道这个论题我喜欢。 早想写一点文字，来纪念我TDD的失 ...
-- by kozyan -
测试驱动？很傻很天真
同情，很傻很天真
-- by passyt -
BNF范式
确实很有兴趣，刚刚学习完状态机的部分，对比一下CT中状态机的实现，很有收获
-- by yananay -
BNF范式
看来你对编译知识很有兴趣, 希望你能有所突破. BNF本身并不复杂, 只是表达 ...
-- by javatar -
CT中表达式处理的思考
你考虑的很对, 当时设计时, 我也考虑过这个问题, 在编译原理中, 通常都会把" ...
-- by javatar
评论排行榜