数据管理

DBMS的中文译名是“数据库管理系统”。指的是管理数据库的系统。它并不负责数据管理。它的责任是库管理。可以把它想象成一个数据服务系统。也就是说，RAW DATA不好访问当然就不好管理，而DBMS提供了DDL，DML等语句可以方便地对数据库进行访问，所以当然也就方便了管理，所以才叫它数据库管理系统。当然在人力以外，它本质上也实现了很大一部分的库管理工作。但是数据它是管不了的，它也没有办法管。

加上HIBERNATE以后的系统也不能管。正好相反，在缺乏正确理解并应用，或者说即使在正确理解的情况下也并不是不可能发生的情况下，数据很可能会整得越来越乱。

数据管理是一个非常棘手的问题。缓存，回写，事务，并发。并且光并发就有多个层次上的并发。事务又有多个层次上的事务。缓存就更加不用说了，复杂得不得了。一个大一点的系统可能会有几十层缓存。

如何处理这些东西 ？

没有缓存，再加上比较严格的事务控制，应该能够在很大程度上解决数据的正确性问题。数据的正确性远远不止ACID四项。数据的正确性范畴比这宽得多。事务本身也比这宽得多。

人们设计一个系统的目的是为了生产。是为了使用它。世界上从来没有完美的东西，更没有完美的软件。数据会出错，性能会下降，维护会出问题......甚至经常性的，系统在功能上从来就没有停止过犯错误。总之，从来就没有一项是不会有问题的。我关心数据，我关心性能，我也关心系统的进化能力，我还关心系统的维护与运营成本，但我更关心我现在所关心的。

一个人，写程序的时间越长，他越倾向地去关心一些非常基础的问题：比如程序员的素质、用户的价值系统、架构的跨平台跨时间能力、系统的开发范式、并发/任务模型等等。因为这些才是系统最大的成本所在。比如你要是请了一个错误的程序员，他很容易就可能使项目走向错误的方向（导致很多不必要且费力不讨好的工时开销/而另一边该集中精力去做好的部分却一团糟----人是最重要的因素）；或者说因为从开发一开始就对用户的某个价值存在重大误解因此导致对开发成果的整体推翻；平台选错导致巨额重构或移植成本；一个需要采用真OO的项目却只采用了伪OO因此工作成果的大面积无效。