近日twitter留言整理

数据库的架构与设计，应该从整体的范围去看问题，要从“

数据存储和管理服务”的角度，而不是“数据库软件”

应用层开发阶段，可以不加入外键，在数据库运营阶段，由DBA补完

ID列的主键身份，其实只是为了与ORM妥协，在很多情况下，一个表只有ID主键列，既危险又愚蠢。如果应用层存在BUG，就会引发严重问题。我的建议是，至少在运营前期，就为关键实体数据加上唯一索引。

存储过程有没有用？这个要看情况。做数据库架构就像建筑工程，不是“对”“不对”这么简单。早年Oracle宣传一切逻辑都封装在存储过程中，数只从存储过程访问，这叫蛋疼。后来MySQL宣传外键存储过程触发器都不需要，只要能增删改查，这叫犯二。

一个数据库要如何设计，业务对数据可靠性、完整性、性能的需求平衡是一个很重要的因素。对于用户访问日志（包括点击率等等），有一定的误差也是允许的，而商务活动往往是不允许有哪怕毫厘之差。针对不同的业务，应该有不同的设计和架构方案。

上次李元佳先生介绍的EDB集群方案给我一定启发。典型的集群节点可以每节点由三个机器组成：一个查询节点，一个写入节点，一个备份节点。写入节点和备份节点多出来的内存可以共享给查询节点做为无限缓存（EDB特有功能）。

有时查询节点还要负担起OLAP的任务，或者本身统计查询的计算量就远大于写入量，此时可以由一个写入节点带多个查询节点，或者直接向一个EDB网格同步。当然网格化以后，写入性能通常会有接近线性提升，这样可能就不需要写入节点了。

前段时间我写过一篇文章，合理利用触发器，可以把一个无限增长的日志表访问，变成限定于20条数据的访问，如果按现在流行的MySQL+ORM，这种东西是做不出来的。

事实上很多项目，尤其是高负载的互联网应用，最终都没有使用ORM。既然如此，拒绝数据库服务端编程就是一件很奇怪的事。在数据库服务端进行合理的编程，可以大大提高性能。

既然数据库服务是作为一个整体使用的，那么性能分析也要从整体考虑。有些功能虽然单独比较性能不高，但是却能在合适的时候，提高应用的整体性能。

数据库设计要符合业务，不要拿来作为自己炫技的场所。

虽然这年头是个人都知道出来吼一句“数据库太慢！”以显示自己牛B，但实际上有多少是真的牛B到跨过了关系型数据库的极限，有多少只是不懂数据库在那里装B呢？

观点：DBA的职责，除了维护工作，应该有以下几个——帮助设计人员找出性能和安全方面的问题；帮助开发人员解决数据库方面的问题，例如一些用其它手段难以解决的性能瓶颈和复杂逻辑；协助架构师制定系统持久层架构；为乙方（通常是DBA就职的一方）提供架构方面的专业意见。

个人认为大多数应用不应该出现大量存储过程，尤其在ORM比较成熟的现今，基本不需要为CRUD操作封装存储过程，而存储过程不能与用户多步交互执行，这就决定了它不会主导事务处理逻辑。但是存储过程可以简化复杂的事务逻辑。

简单的说，存储过程最好是在开发由粗到精的优化过程中加入，代替需要优化的代码部分。如果是那种希望快速粗放的拼装一个项目然后交钥匙不管的初等级开发（不要拿这个来冒充XP过程）并不适合过多使用存储过程，最好是用熟ORM，积累并复用确实有效的一些存储过程和SQL脚本模板。