一直以来一直有个狂妄的想法，希望应用的创建能够变成数据库中表与关系的简单控制。
我不知道这是不是一种不可理喻的想法，但还是觉得某些重复性强，业务逻辑相似的应用应该通过数据表或者是配置文件的变化去控制。
我更相信前者能够做得更好。当然所有的前提是，有个完美的sql语句生成工具，语句要精炼，并且高效。姑且成为智能sql工具吧，毕竟需要在表关系复杂的情况下，能够产生合理的sql语句，这和智能化的控制策略脱离不了关系。希望有这样一个工具，纯粹是出于降低重复劳动量的目的。而且很多时候人为的错误实在是个让人头疼的问题，往往一个疏忽就要一天时间做纠正。是时候希望一种，以长久经验总结的工具，让错误变少。
这些都是我的一种想法，目前也正化为一种行动的方向。在这次阳光网的改版中，我们优先做的是应用架构的开发。说开发有点夸大了，但毕竟还是规矩的去做些事情。rbac0的实现，mvc模型，模板引擎，应用分层等等，从参照了相关标准性（这一点也一直让我乐道）的东西，到针对阳光网的需要做了一个“布局管理”模型，以求灵活多变。所有的这些，用软件工程的话来讲，是个复杂的编码的过程，同时也是我们自主设计创意的过程。
不得不说，数据库是个好东西，而web dbms更是一个好东西。虽然后者没有用过，但相信理念还是和桌面dbms有异曲同工之处吧。
通过web而非桌面，管理数据库中的所有资源，甚至能够借助改变数据库中的资源分配，去影响整个应用系统的运行方式。继而之，在未来，系统发生变更，或者维护拓展的时候，通用能够借助此方式以最低的消耗解决问题。
这里有几个问题是需要解决的。
首先，从数据库考虑，良好的sql语句来自于人的思考，很多的经典的sql语句需要总结成库。为了更好的控制数据库，系统肯定需要自身的系统数据库（非数据库的系统表），这些表或者模式尽可能只与应用系统有关，与真实业务联系较少，简而言之就是为应用架构服务的数据表。更好的系统完善策略，像在我们建立之初，通过传统方式建立基本应用，再在基本应用之上建立新应用，每一次的建立都依赖于前面的工具，同时又能够为下一次应用提供创建支持等。有点像是为应用建立应用，为开发建立自身的开发工具的感觉。
但我更倾向性认为，系统能够在人为的干预控制之下，完成自身功能的拓展，和应用服务的更高层抽象，是系统成长的关键。
更希望的数据库是知识库，应用是智能系统。
在拓展在学习在成长。内涵越多，外延同样应该越深。
当然，不良的后果就是越来越臃肿。
应用能否感知自身的进化呢！