|
|
文章一般般，讲的不深入并且很凌乱
本人是不建议在数据库里面放入任何业务逻辑相关的东西
参考一些大的系统来看，做法也不一样。例如SAP，基本上只用最简单的SELECT、DELETE、UPDATE、INSERT语句，来实现整个SAP系统的业务逻辑，很方便实现多数据库支持；而Oracle ERP，大量的使用Procedure等Oracle数据库特性来实现核心业务，有一个重要因素，因为Oracle数据库本身也是他们自己开发的，绑定起来有重要的意义，开发中也可以互相支持。
如果参照SAP的方式来做，数据库的设计感觉上变得非常朴实，不会有什么花销的地方，但每一处设计又都是很有思想。
举个例子来说，不管你的系统业务逻辑有多复杂（一般来说总不会比SAP系统还复杂），你要能够只用最基础的SELECT、DELETE、UPDATE、INSERT（也就是说不使用JOIN、子查询等）来实现，并且保证系统良好的性能，不简单！
关键在于业务分析，系统架构、设计，数据库层的功能变得非常单纯（当然不是说数据库的设计上变得简单）。
其实这才是设计之道，也应该是OO的理念。
罗嗦半天，其实是想说明我的系统数据库设计理念，估计也没有说的明白，大家按照上面提出的问题仔细思考，应该可以领会些东西。
最初由 wangyuzhen 发布
[B]个人认为，数据库设计是一个良好系统的根基，一切的一切都要通过数据库来得到固化（或称作“持久化”）。而一个系统的效率很大程度上都取决于数据库的效率，特别是一些中等规模的MIS系统。系统是建立在对企业业务流程理解的基础上的，一般的信息系统只是把这种管理模式给固化下来，高层次的信息系统才能谈优化流程和提高管理水平（也许这也还是咨询顾问的事情）。
数据库设计一般来说能达到第三范式就很不错了（至于什么是第三范式可以自己查找数据库原理方面的资料），小系统可以不在数据库内部建立触发器、存储过程、外键什么的，这种逻辑可以放在代码里完成，以后修改逻辑就直接修改代码，不过代码应该按照一定的规则进行模块划分这样便于以后的修改和升级。
大一些的系统就必须考虑在数据库端做些“手脚”触发器、存储过程、外键什么的都要用上了，这样做可以简化显示层的代码，便于维护。不过，我始终都没有好好设计过一个通过数据库后台程序来简化系统GUI层的系统——实在是水平和认识不够。
不过现在在面相对象思想的指导下，很多时候我们都忽略了数据库的设计，很多建模工具可以从业务流、用例（Use Case）、概念模型、O－R映射、物理模型一直到数据库建立都可以自动完成。实际上这些工具自动生成的数据库模型难道都是很优化的吗？很实用的吗？以前一直不理解什么是JavaBean，前一段时间有了些领悟，发现所谓的Bean就是一个自动把对象属性存入数据库的东西，当然这只是Bean的一个作用，可能还有其他更重要的功能我还没有认识到。也就是把我们写的Item.New()转换成Insert...，Item.Set(Value)转换成Update......。
现在的程序员对后台数据库的认识太少了，或许是分工的原因，但是我觉得还是要了解一些比较好。毕竟，数据库是一个完整系统的重要组成部分，缺少对数据库的了解很难在系统设计上有所提高，大家不是一辈子都当编代码的程序员吧。 [/B] |
|
楼主: ccwlm74121
IP卡
狗仔卡
发表于 2006-4-11 20:42
显身卡
