且听风吟

最近事情比较多，适得些许空闲。遂记录一下这段时间以来 相关于 项目的一些心得。 纯属个人拙见，如有不当之处，请勿苟同。(^__^) 嘻嘻……

---

E-R

故事还得从MySQL数据库开始，一开始还是受别人建议，装的MySQL。然后什么都不懂，就瞎装一通，也不知道是运气好还是咋的，最后竟然成功的安装了。

然后还是什么都不懂，稀里糊涂的， 当然了，更别说用了。面对这么个陌生的事物，一开始，我是拒绝的。一下子就吃掉了我系统盘好多存储容量，这换谁也开心不起来不是。

然后依稀记得，有一次同学在黑黑的命令行下输入着什么东西，瞬间感觉叼叼哒。 然后就问了问他在干什么？然后我就知道了，噢。原来数据库可以这样操作啊。

然后，到图书馆借了本书，薄薄的一个手册，也就百十来页吧。对照着上面的命令，熟悉了一把。然后就习惯了使用命令行来操作数据库了。这段时间，虽然没什么大的长进，但是DDL， DML，SQL语句倒是练了个熟。（毕竟，打错一个字符，整个语句就得重来，这感觉确实不咋地。）

再后来，看到视频上一个老师用了一个软件，可以修改SQL语句，这样。写错了也不用重来一遍了。这真的是忒爽了，有木有？然后我就偷偷的记下来那个软件的图标，然后就遇到了Navicat。后来就基本上不怎么使用命令行来操作数据库了。

好景不长，这次要设计一个数据库系统。手动的画图感觉真的很慢，而且准确性也不能得到保证。经过搜索，原来几十年前就有前辈遇到这样的问题，并给出了不错的解决方案了。（看来自己真的是没见过什么世面呢）
。然后嘛，发现mysql竟然自带了Workbench。然后我就按照：学过的1NF, 2NF, 3NF, BCNF等。画了一个自认为还不错的E-R图。

然后竟然可以直接由model生成数据库了。真的是方便极了。

话虽如此，但是基础是不容忽视的。我还是比较喜欢当时在命令行下手敲一大串代码， 成功运行的那种畅快的feel。

实体与模型

这里有点断章取义。大致的含义就是设计好数据库之后，要怎样搭配实体才能起到一个很好的效果。

一开始我使用的是类似于JPA核心思想的那样，数据库设计成什么样，实体bean就设计成什么样。这样的好处在于可以很轻松的构建关系型数据库与Java对象之间的逻辑。 冗余数据的存在给此后的数据处理带来了某种程度上的方便。

但是慢慢的，我发现。据此创建的实体的很多的属性是没什么用的，有些甚至就没用到过。反而给程序的构造查询流程带来了过多的参数困扰。
然后，我就自己思考了一下。

按照需求来设计实体，兼顾数据库中模型。

也就是说，Bean只会包括哪些必要的属性。 至于怎么来定义必要？我个人的理解就是思考系统需求，使用到那些参数，就对应着将其封装成一个Bean。这些Bean就是对应于数据库模型的等价。

说白了，我自己这块是这样来处理的。

• 主键， 去掉
• 外键， 如实表达
• 必备属性， 如实表示

可能和其他的编程风格，有点不同。但是这个方法对于我本次的这个小项目而言，确实大大简化了我的编码， 减轻了思维上的负担。至于这个方式是不是真的不错，还得在今后的实践中加以验证。

不管怎样，每个人的风格都有所不同，找到适合自己的，那就足够了。

---

设计

一直以来，对于整个项目流程，思路都不是特别的明朗。但是经过近段时间以来的思考，我也算是发现了一个比较适合自己的“套路”了。

自下而上

对那些自己用的东西而言，大部分需求都很简单，基本上都是一两个功能。所以我基本上会从功能出发，完成一个个的小的功能，然后在拼装成整个工具。

这点的好处，可能就在于：

能比较透彻的把握整个工具，不会添加一些不能实现的功能吧。

因为，但是也缺乏了一定的宏观把握能力。不能很好的进行拓展。

自顶向下

这个说法也可以说是从需求的角度出发，然后解剖出单个的模块。在具体的实现每个模块的功能，再向下细化每一个小功能，乃至小函数的实现。

这样的好处就是能比较透彻的把握整体，但是有可能会异想天开的加入一些炫酷的然而最终并不能实现的功能。

二者比较

其实，这两个方式各有各的好处。侧重点不同罢了。可能，对于项目而言，后者更为适合，大量的需求分析以及开发模式能很好的控制整个项目的进度。

但是开发一个自用的小工具，或者写个自动化脚本啥的。后者就未免有点大材小用了。使用前者显得更加的务实一点。

总结

貌似和一开始心中自己想说的有点跑偏，但竟然也能废话连篇的说了这么多。

杂感嘛，终归“杂”， “感”二字。有思考才能有进步的空间，也许。我们每个人都应该适时的停下匆忙奔波的脚步，思考一下，小憩一时，或许会有不一样的收获。

                                      --郭璞                                      于 大工 软院 图书馆 二楼 西南角