初学感悟-1-数据库乱谈
5 views
Skip to first unread message
wj1s
Dec 9, 2005, 4:51:20 AM12/9/05
to Programmer Cafe
提笔前已经想了近30分钟，甚至连想所表达的个人观点都没总结出来，也许就是初学者的悲哀，似有所悟，又表达不出来，本来不想丢这个人，被逼的，哈哈。
废话不说了，就想到哪写到哪，就当给此时的记忆打个标签了。
我主要想说的是自己对于数据库在项目分析设计阶段的一些小想法。我觉得，数据库只是一个存储数据的地方，像一个工具一样，或许说就是一个工具，它的作用只是在我们需要保存一些数据以供我们将来使用的时候，提供一个场所保存（理所当然还有其他的场所可以保存数据，例如XML），不应该把数据库设计过早的在分析设计阶段加入，更不该把数据库设计做为程序开发的入口。在上学的时候，做一个这成绩查询系统那借书系统（基本上就这两个-_-||），记得所有人都是一开始就把数据库洋洋洒洒的搭起来先，然后就是一个界面，增删改查；第二个界面，增删改查。可是当系统变大了，对象关系复杂了，我觉得一开始就进行数据库设计就不太合适了，为什么呢？这就是我刚才30分钟想的，但是没想清楚......（都是搞技术的，不许打人，啊）大概来说，我觉得在面向对象里，更多的是要关注将客观的事物合理的抽象为对象，把握对象之间的关系和对象是怎么相互协作来达到最终目的的，对象的数据只是本身的属性而已，在我理解，数据库设计主要是对表的设计，而每个表中所包含的无非是数据和关联，每一个表都有可能是一个实体加关联的混合体，如果我们一开始就陷入实体数据和关联的双重夹击中，而且无论是属性还是关联都是不稳定的，就算我们辛辛苦苦建立了一堆表，也许会发现表的关系错综复杂，外键满天飞，关联到处是，用到一个属性加一个属性......（再次声明，反正我是这样的，高人不在本文讨论范围之内，呵呵）。而且在意识中没有一个整体的概念，表一但确定了就惯性思维很难再去管他的对错和是否舒服，围绕着这些还不知道是否正确的表，进行程序的开发，很容易被引的离正确简洁的方向越来越远。
而相比数据来说，对象则是相对稳定的，而且因为对象的本身属性与对象之间的关联是没有关系的，可以分开讨论，一开始先讨论概念之间的关系，减少不必要的关联，使对象之间的关系明确简洁，然后再确定每个对象本身的属性，当概念模型稳定并可以实现系统功能的时候再进行持久层的设计，将对象的关联自根据其之间的可见性和多重性的关系加入到相互关联的一个或两个对象中，就形成了关联属性，这样就顺水推舟的从概念分析转到持久层的设计，当然两个对象之间的关系，反映到数据库中可以有多种表达方式，而且没有对错，不同情况对应不同的方式，但是对象的关系是稳定的，这也证明了对象的关系要比表的关系稳定的多。（有点拗口，对不住。。）
说到这不知道听糊涂了多少人，，最后总结一下，这些东西没有对错，应该在不同应用需求下灵活采取最优的方法，但是个人建议所有的像我一样刚掉进编程海洋的苦难同胞们，将更多的精力投入到对对象的提取和分析，不要困在数据库设计中，也许有一天会觉得数据库中那些破表的形成是那么自然而优雅。
最后声明，现在网上好多人在吵，关于数据库什么终结时代到临什么的，都是大家之谈，我等小鸟，没资格谈这些，其实我觉得大家所说的数据库时代所代表的意义都是不同的，所以吵的没意义。不过要锻炼面向对象的看待问题方法是没错的。废话较多，大家担待。
废话不说了，就想到哪写到哪，就当给此时的记忆打个标签了。
我主要想说的是自己对于数据库在项目分析设计阶段的一些小想法。我觉得，数据库只是一个存储数据的地方，像一个工具一样，或许说就是一个工具，它的作用只是在我们需要保存一些数据以供我们将来使用的时候，提供一个场所保存（理所当然还有其他的场所可以保存数据，例如XML），不应该把数据库设计过早的在分析设计阶段加入，更不该把数据库设计做为程序开发的入口。在上学的时候，做一个这成绩查询系统那借书系统（基本上就这两个-_-||），记得所有人都是一开始就把数据库洋洋洒洒的搭起来先，然后就是一个界面，增删改查；第二个界面，增删改查。可是当系统变大了，对象关系复杂了，我觉得一开始就进行数据库设计就不太合适了，为什么呢？这就是我刚才30分钟想的，但是没想清楚......（都是搞技术的，不许打人，啊）大概来说，我觉得在面向对象里，更多的是要关注将客观的事物合理的抽象为对象，把握对象之间的关系和对象是怎么相互协作来达到最终目的的，对象的数据只是本身的属性而已，在我理解，数据库设计主要是对表的设计，而每个表中所包含的无非是数据和关联，每一个表都有可能是一个实体加关联的混合体，如果我们一开始就陷入实体数据和关联的双重夹击中，而且无论是属性还是关联都是不稳定的，就算我们辛辛苦苦建立了一堆表，也许会发现表的关系错综复杂，外键满天飞，关联到处是，用到一个属性加一个属性......（再次声明，反正我是这样的，高人不在本文讨论范围之内，呵呵）。而且在意识中没有一个整体的概念，表一但确定了就惯性思维很难再去管他的对错和是否舒服，围绕着这些还不知道是否正确的表，进行程序的开发，很容易被引的离正确简洁的方向越来越远。
而相比数据来说，对象则是相对稳定的，而且因为对象的本身属性与对象之间的关联是没有关系的，可以分开讨论，一开始先讨论概念之间的关系，减少不必要的关联，使对象之间的关系明确简洁，然后再确定每个对象本身的属性，当概念模型稳定并可以实现系统功能的时候再进行持久层的设计，将对象的关联自根据其之间的可见性和多重性的关系加入到相互关联的一个或两个对象中，就形成了关联属性，这样就顺水推舟的从概念分析转到持久层的设计，当然两个对象之间的关系，反映到数据库中可以有多种表达方式，而且没有对错，不同情况对应不同的方式，但是对象的关系是稳定的，这也证明了对象的关系要比表的关系稳定的多。（有点拗口，对不住。。）
说到这不知道听糊涂了多少人，，最后总结一下，这些东西没有对错，应该在不同应用需求下灵活采取最优的方法，但是个人建议所有的像我一样刚掉进编程海洋的苦难同胞们，将更多的精力投入到对对象的提取和分析，不要困在数据库设计中，也许有一天会觉得数据库中那些破表的形成是那么自然而优雅。
最后声明，现在网上好多人在吵，关于数据库什么终结时代到临什么的，都是大家之谈，我等小鸟，没资格谈这些，其实我觉得大家所说的数据库时代所代表的意义都是不同的，所以吵的没意义。不过要锻炼面向对象的看待问题方法是没错的。废话较多，大家担待。
caicai
Dec 9, 2005, 5:03:36 AM12/9/05
to program...@googlegroups.com
面向对象分析设计是被很多人挂在嘴边上的东东，但是真正能够理解的人不多。
你说的很对，在分析设计初期不应该陷入技术细节中去，应该现把概念层的东西搞清楚，在一步步细化。面向对象分析设计方法为我们提供了一个很有用的方法论，可以让我们做到这一点。
好处是什么？如果你习惯这样分析问题了以后，在各个阶段都可以对你的对象模型进行验证和确认，并且可以和其他设计要素关联起来，进行交叉验证。在设计最后的数据库物理模型之前，你将得到一个良好的模型，根据他导出数据库设计，数据库结构会比较符合业务上的客观要求，就是一个高质量的数据结构设计。
你说的很对，在分析设计初期不应该陷入技术细节中去，应该现把概念层的东西搞清楚，在一步步细化。面向对象分析设计方法为我们提供了一个很有用的方法论，可以让我们做到这一点。
好处是什么？如果你习惯这样分析问题了以后，在各个阶段都可以对你的对象模型进行验证和确认，并且可以和其他设计要素关联起来，进行交叉验证。在设计最后的数据库物理模型之前，你将得到一个良好的模型，根据他导出数据库设计，数据库结构会比较符合业务上的客观要求，就是一个高质量的数据结构设计。
On 12/9/05, wj1s <wa...@arcturus.com.cn> wrote:
......
而相比数据来说，对象则是相对稳定的，而且因为对象的本身属性与对象之间的关联是没有关系的，可以分开讨论，一开始先讨论概念之间的关系，减少不必要的关联，使对象之间的关系明确简洁，然后再确定每个对象本身的属性，当概念模型稳定并可以实现系统功能的时候再进行持久层的设计，将对象的关联自根据其之间的可见性和多重性的关系加入到相互关联的一个或两个对象中，就形成了关联属性，这样就顺水推舟的从概念分析转到持久层的设计，当然两个对象之间的关系，反映到数据库中可以有多种表达方式，而且没有对错，不同情况对应不同的方式，但是对象的关系是稳定的，这也证明了对象的关系要比表的关系稳定的多。（有点拗口，对不住。。）
说到这不知道听糊涂了多少人，，最后总结一下，这些东西没有对错，应该在不同应用需求下灵活采取最优的方法，但是个人建议所有的像我一样刚掉进编程海洋的苦难同胞们，将更多的精力投入到对对象的提取和分析，不要困在数据库设计中，也许有一天会觉得数据库中那些破表的形成是那么自然而优雅。
......
项维炜
Dec 9, 2005, 7:31:01 AM12/9/05
to program...@googlegroups.com
写的非常不错！我都叫我同事来看了
wj1s
Dec 9, 2005, 9:07:14 AM12/9/05
to Programmer Cafe
呵呵,谢谢.
皮毛而已,本来就不好意思写,因为对数据库的认识太浅了,没发言权,被逼的呵呵
项哥也长来写点感想什么的
看你的blog上文章更新的也挺长见识的
皮毛而已,本来就不好意思写,因为对数据库的认识太浅了,没发言权,被逼的呵呵
项哥也长来写点感想什么的
看你的blog上文章更新的也挺长见识的
Stone Jiang
Dec 9, 2005, 9:09:48 AM12/9/05
to program...@googlegroups.com
很多地方有同感.
不必在需求还不稳定的时候就考虑数据库的设计.最好等到对象模型出来后,再确定哪些可持久化到关系数据库中.
刚翻出一本书:
Addison Wesley - UML for Database Design.chm
还没看呢.
--
Yours,
Stone Jiang
gTalk: 200...@gmail.com
不必在需求还不稳定的时候就考虑数据库的设计.最好等到对象模型出来后,再确定哪些可持久化到关系数据库中.
刚翻出一本书:
Addison Wesley - UML for Database Design.chm
还没看呢.
在05-12-9，wj1s <wa...@arcturus.com.cn> 写道：
--
Yours,
Stone Jiang
gTalk: 200...@gmail.com
Stone Jiang
Dec 9, 2005, 9:13:14 AM12/9/05
to program...@googlegroups.com
blog 在哪呢?:)
在05-12-9，wj1s <wa...@arcturus.com.cn> 写道：
呵呵,谢谢.
皮毛而已,本来就不好意思写,因为对数据库的认识太浅了,没发言权,被逼的呵呵
项哥也长来写点感想什么的
看你的blog上文章更新的也挺长见识的
wj1s
Dec 9, 2005, 9:22:50 AM12/9/05
to Programmer Cafe
这也许就是我那30分钟想的那句话,呵呵
这么多人看我的文章很感激,请大家也同样关注一下JAMES的JDK
Overview,其实它的价值要远远大于我这么个笔记
现在技术漫天飞,其实这些最基本的才是最可贵的,也是最稳定的
但是好象没人回贴
OVER
这么多人看我的文章很感激,请大家也同样关注一下JAMES的JDK
Overview,其实它的价值要远远大于我这么个笔记
现在技术漫天飞,其实这些最基本的才是最可贵的,也是最稳定的
但是好象没人回贴
OVER
杨乃印
Dec 9, 2005, 9:37:24 AM12/9/05
to Programmer Cafe
楼主指出了设计的一个普遍现象。
正如楼上所说，在分析设计阶段，如果抽象出对象是最关键的。
另外，有些时候之所以从数据库出发，除了“本末倒置”的错误之外，还可能存在某种习惯性的模式，即所谓的“持久层模式”（个人用模式来表达是因为这种持久层设计具有普遍性），在这种情况下，或许能适当的加快步伐。
正如楼上所说，在分析设计阶段，如果抽象出对象是最关键的。
另外，有些时候之所以从数据库出发，除了“本末倒置”的错误之外，还可能存在某种习惯性的模式，即所谓的“持久层模式”（个人用模式来表达是因为这种持久层设计具有普遍性），在这种情况下，或许能适当的加快步伐。
jop
Dec 9, 2005, 9:32:54 AM12/9/05
to program...@googlegroups.com
nighthawk
Dec 9, 2005, 11:34:14 PM12/9/05
to Programmer Cafe
嘿嘿！回到主题。站在开发人员的角度上wj1s的意见我表示99%的赞同，但是DBA们肯定会向你扔砖头。如果你是项目经理，他们就都可以走人了：）。然而，事实却并非这样！
为了不引起争论，我们姑且不讨论Object-Driven Modeling
与Database-Driven
Modeling哪个更有优势。但在这里，我暂以Object-Driven
Modeling的开发为前提。即使对象分析建模等等一切都顺利，编码也很顺利。然而，作为一个小有规模的项目，在对象数据库没出来之前，开发人员就真的很有把握的将对象很好的转换为关系数据库中的表么？我看未必。记住：不要把全部希望寄托在程序员去做DBA的事，也不要让DBA去指导程序员的开发。要完成一个高效简洁的关系数据库设计看起来似乎也没那么简单。一个完整的TEAM，这2个角色必然存在。要想消除这种分歧，最好的方法就是：沟通！数据库设计人员必须参与到模型设计中来。这样似乎才是解决问题的办法。吃饭前写的，未经推敲，欢迎拍砖。
为了不引起争论，我们姑且不讨论Object-Driven Modeling
与Database-Driven
Modeling哪个更有优势。但在这里，我暂以Object-Driven
Modeling的开发为前提。即使对象分析建模等等一切都顺利，编码也很顺利。然而，作为一个小有规模的项目，在对象数据库没出来之前，开发人员就真的很有把握的将对象很好的转换为关系数据库中的表么？我看未必。记住：不要把全部希望寄托在程序员去做DBA的事，也不要让DBA去指导程序员的开发。要完成一个高效简洁的关系数据库设计看起来似乎也没那么简单。一个完整的TEAM，这2个角色必然存在。要想消除这种分歧，最好的方法就是：沟通！数据库设计人员必须参与到模型设计中来。这样似乎才是解决问题的办法。吃饭前写的，未经推敲，欢迎拍砖。
Qian Xin
Dec 9, 2005, 6:01:03 PM12/9/05
to program...@googlegroups.com
Many projects, they give money on how many tables you have designed for them
in the project...
in the project...
wj1s
Dec 10, 2005, 9:42:06 AM12/10/05
to Programmer Cafe
终于等到不用的意见了,呵呵
那天在和一些新接触这方面的人的讲的时候,一开始我很自信的说,记住不要老围绕着数据库转,你们看,这样,这样把关系搞清楚,再来设计数据库.....你看....当我想说数据库就这么轻松的建立的时候我没说出口
这也是这篇半任务性质的文章考虑了很久的原因,因为我发现自己在分析的同时也在不自觉考虑这种分析方式最终将如何映射成数据库,映射出来的是否舒服.当然我接触的系统十分的简单,可以在脑子中验证正确性,所以感觉上是一个顺序的过程,先对象后数据库,但是正如顺序图和类图是谁先产生的,程序的开发方式一样,所有过程都好象是在重叠的进行,这也正式我迷惑的地方,也正式不敢提笔的所在,因为这些关系还没有搞清楚.
也许是不是可以考虑将RUP中的迭代引入其中,讨论谁先谁后的问题应该意义不大,如果分成不同的小块,每一个迭代都把对象和数据库做一点,然后考虑相互的关系,再从头到尾做一次,再考虑.将两者的关系尽量达到一个平衡而稳定的状态.对迭代的关系不太清楚,如果这里引用错请指正.
也许我这小段字的意义就是希望大家关注一下对象,本意不是讨论那种更好,说实话现在还拿捏不好两者的细微关系,才刚上路呢(广告词),呵呵..
最后希望大家别乱仍砖头,危险,扔点西红柿啥的多好...
那天在和一些新接触这方面的人的讲的时候,一开始我很自信的说,记住不要老围绕着数据库转,你们看,这样,这样把关系搞清楚,再来设计数据库.....你看....当我想说数据库就这么轻松的建立的时候我没说出口
这也是这篇半任务性质的文章考虑了很久的原因,因为我发现自己在分析的同时也在不自觉考虑这种分析方式最终将如何映射成数据库,映射出来的是否舒服.当然我接触的系统十分的简单,可以在脑子中验证正确性,所以感觉上是一个顺序的过程,先对象后数据库,但是正如顺序图和类图是谁先产生的,程序的开发方式一样,所有过程都好象是在重叠的进行,这也正式我迷惑的地方,也正式不敢提笔的所在,因为这些关系还没有搞清楚.
也许是不是可以考虑将RUP中的迭代引入其中,讨论谁先谁后的问题应该意义不大,如果分成不同的小块,每一个迭代都把对象和数据库做一点,然后考虑相互的关系,再从头到尾做一次,再考虑.将两者的关系尽量达到一个平衡而稳定的状态.对迭代的关系不太清楚,如果这里引用错请指正.
也许我这小段字的意义就是希望大家关注一下对象,本意不是讨论那种更好,说实话现在还拿捏不好两者的细微关系,才刚上路呢(广告词),呵呵..
最后希望大家别乱仍砖头,危险,扔点西红柿啥的多好...
James Chan
Dec 11, 2005, 10:04:39 PM12/11/05
to program...@googlegroups.com
也感怀一下xxx-Driven Modeling的问题。
在很久很久以前，大概是上个世纪80年代早期，那个时候大家都很“穷”，还没有像现
在这么好的数据库。所以那个时候大家的要求也没这么“高”——只要有个程序能在内
存中运行就可以了。一旦断电，一切重新来过就好了。从这个角度来说，数据库是驱动
不了系统的。
后来呢，随着电力供应紧张，断电事故总是不断地发生。为此一些勇士下定决心“一定
要把数据存起来！”。经过不懈的努力，终于他们成功了。有了数据库，有了好多好多
很好的数据库。接下来，他们老了，去世了。但是在去世之前，忘了告诉后人他们的动
机。后人们自然也就渐渐地淡忘了数据库诞生，只是习惯了有这么个好东西。一句
话——好东东但求会用，不求甚解。
不知道从哪一天起，所有的应用都必须要有数据库了。随着时间的流逝，些许理论家经
过“艰苦而卓绝的研究”之后，发明了“Database-Driven Modeling”的理论。一时
间，普天同庆，群情激昂。
这个时候，一个傻瓜在人群中说——如果我的应用不需要保存数据，而只是想在内存中
运行着玩，那该怎么办呢？人群在一阵沉默之后选择了爆发——用鄙夷的眼光掐死那个
傻瓜——应用不可能不需要保存数据，既然要保存数据，那么数据库就可以驱动应用的
开发。
大家的威慑起了作用，那个傻家伙，小声地认错道：我不是说数据库不重要，只是说只
有在需要持久化的时候，才用它，所以它驱动不了整个软件开发过程——因为在代码完
成之前我妈还没告诉我要把数据保存起来呢。
顿时，扬起笑声一片，他妈没告诉他要把数据存起来，原来他真的是个傻子。
——本文纯属虚构，若有雷同纯属巧合。
——为Programmer在紧张的工作之余，奉上一杯怪味Cafe。
-----邮件原件-----
发件人: program...@googlegroups.com [mailto:programmercafe@googlegroups.
com] 代表 nighthawk
发送时间: 2005年12月10日 12:34
收件人: Programmer Cafe
主题: [Programmer Cafe] Re: 初学感悟-1-数据库乱谈
嘿嘿！回到主题。站在开发人员的角度上wj1s的意见我表示99%的赞同，但是DBA们肯定
会向你扔砖头。如果你是项目经理，他们就都可以走人了：）。然而，事实却并非这
样！
在很久很久以前，大概是上个世纪80年代早期，那个时候大家都很“穷”，还没有像现
在这么好的数据库。所以那个时候大家的要求也没这么“高”——只要有个程序能在内
存中运行就可以了。一旦断电，一切重新来过就好了。从这个角度来说，数据库是驱动
不了系统的。
后来呢，随着电力供应紧张，断电事故总是不断地发生。为此一些勇士下定决心“一定
要把数据存起来！”。经过不懈的努力，终于他们成功了。有了数据库，有了好多好多
很好的数据库。接下来，他们老了，去世了。但是在去世之前，忘了告诉后人他们的动
机。后人们自然也就渐渐地淡忘了数据库诞生，只是习惯了有这么个好东西。一句
话——好东东但求会用，不求甚解。
不知道从哪一天起，所有的应用都必须要有数据库了。随着时间的流逝，些许理论家经
过“艰苦而卓绝的研究”之后，发明了“Database-Driven Modeling”的理论。一时
间，普天同庆，群情激昂。
这个时候，一个傻瓜在人群中说——如果我的应用不需要保存数据，而只是想在内存中
运行着玩，那该怎么办呢？人群在一阵沉默之后选择了爆发——用鄙夷的眼光掐死那个
傻瓜——应用不可能不需要保存数据，既然要保存数据，那么数据库就可以驱动应用的
开发。
大家的威慑起了作用，那个傻家伙，小声地认错道：我不是说数据库不重要，只是说只
有在需要持久化的时候，才用它，所以它驱动不了整个软件开发过程——因为在代码完
成之前我妈还没告诉我要把数据保存起来呢。
顿时，扬起笑声一片，他妈没告诉他要把数据存起来，原来他真的是个傻子。
——本文纯属虚构，若有雷同纯属巧合。
——为Programmer在紧张的工作之余，奉上一杯怪味Cafe。
-----邮件原件-----
发件人: program...@googlegroups.com [mailto:programmercafe@googlegroups.
com] 代表 nighthawk
发送时间: 2005年12月10日 12:34
收件人: Programmer Cafe
主题: [Programmer Cafe] Re: 初学感悟-1-数据库乱谈
嘿嘿！回到主题。站在开发人员的角度上wj1s的意见我表示99%的赞同，但是DBA们肯定
会向你扔砖头。如果你是项目经理，他们就都可以走人了：）。然而，事实却并非这
样！
huang alex
Dec 15, 2005, 5:49:19 AM12/15/05
to program...@googlegroups.com
我们这学期刚好做数据库课程设计。正好做的也就是楼主说的那些成绩什么系统啦，呵呵～～不过我们老师很郑重其事的跟我们讲数据库的设计呢。让我觉得开发出来的那个系统只是为数据库服务的，所以你用什么语言怎么实现都可以，而是要让数据库符合用户的需求。不过话说回来，我的这个从头到尾才用了两张表，我同学他们那一组一开始想得很美好设计了十多张表，结果最后交作品的时候数据库都没有连接上。看来大学生真的还差得很远呀。
2005/12/10, wj1s <wa...@arcturus.com.cn>:
Reply all
Reply to author
Forward
0 new messages