未来软件是什么样子？－数据库篇
数据库技术是众多应用管理软件的核心部分，有着举足轻重的地位。
如果数据库及其相关技术，能够强大到每天处理百万亿级别的数据，那么相信许多应用软件的性能瓶颈马上可以迎刃而解了。
数据库技术的一个关键是要解决与存储介质之间的Read/Write问题。当前的硬件技术I/O性能问题,就是限制数据库性能的关键因素。在硬件技术目前无法大幅度提高的情况下，在满足相同需求的情况下，减少数据的I/O次数成为了判断数据库算法的优劣的标准。
既然无法大规模的向纵深发展的情况下，只能“曲线救国”，向横向发展。于是众多的数据库分布技术，同步技术，集群技术风风火火的发展起来了。扩展性是其优势，而数据统一性是其代价。
这里有以下不成熟的观点和大家交流，请大家指正。
观点1：数据库和开发环境的统一
当前每次数据库有变更的时候，可能相关的存储过程，视图等也需要变更，并且需要整理数据库升级脚本，变更对应程序并重新编译。这样造成了维护的成本增加。
为什么我们不能在程序源代码中直接定义数据库的结构（表，视图，存储过程等）呢？把数据库和编译器进一步结合呢？直接在源代码中维护数据库结构数据，编译时，如果不符合数据库规则，就直接报错提示。编译器根据不同的数据库，自动的生成对应的数据库变更脚本。甚至还可以结合的更加紧密，数据库文件本身就是开发环境的产物，数据库管理自身仅仅是整个开发环境的一部分。这样的话，甚至不需要另外的数据字典，源代码中定义的数据库结构文件就能实现这一功能。
现在微软的VS2008和SQL2008更加紧密的结合，或许就有那么点意思。LINQ更是向这一方向迈出了一步。
当然，这样的结构，或许安全性会存在一定问题。
观点2：把整个数据库放在内存里
既然内存（L3级Cache）比硬盘（L4级Cache）快，那我们为什么不能将整个数据库放在内存里面呢？
目前的64位的Win2003+已经支持到TB级别的内存量，TB级相信对一般的数据库应用应该已经属于海量了，那我们为什么还要把数据库存储在相对慢许多的硬盘上面呢？即使数据库有几十G，甚至几百G，放在内存中不是就可以马上提升性能了吗？
现在CPU的多核技术也在迅速发展，相信不久的将来8核，16核的CPU也会出现。如果内存数据库中有了变更，分出一个CPU的性能来处理内存数据库和硬盘数据库的同步问题，进而解决了数据库的常态保存问题。
当然，这样处理的话，内存数据库的启动（硬盘数据读取到-->内存）会花费更多的时间，但内存数据库的查询和写入性能会得到数量级的提升。好比我们为什么要使用索引？它导致了新增和更新记录时速度损失，但它极大的提升了查询性能。
说错的地方，请大家批评指正。
相关文章：
