近日 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脚本模板。


--
话题越大，废话越多；名字越火星，问题越脑残。
……

劉鑫
March.Liu

[Zoom.Quiet]

好哪！先语录，片段体会，
慢慢的，抓住重点，就可以扩展成 EDB 故事了...

2009/9/16 刘鑫 <marc...@gmail.com>:

--
http://zoomquiet.org 人生苦短? Pythonic!
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity)http://bit.l...

[刘鑫]

2009/9/16 郑溪 <chupa...@gmail.com>

开发框架在数据库设计的时候就该确定吧，再照应元佳说的集群节点。那么业务逻辑的实现方式也就确定了。

开发者和DBA之间本来就是悖论，SQL放程序里、或者调API/CLI可能会容易些，写存储过程和Triger还会牵涉移植问题，但DBA做Tunning和TroubleShooting就难了。

DBA转做开发就好，架构和需求变得那么快，得累死。

现在还有人用Block Summit吗

开发框架会比较固定，但是现在的应用，很多都遵循“生命期持续开发”的过程。也就是说，只要在用，就会不断修改。其实对这种精耕细作，不断调整的项目，适当引用数据库层编程是非常有意义的。

一、将性能和业务问题放在整个服务层（应用层+数据持久层）的视角来解决，会有更丰富和灵活的手段。
二、大量所谓关系数据库的性能问题，其实都可以通过数据库层编程提供更为高效的接口来解决。我们的开发人员热衷于Hack应用服务器、架设缓存集群、添加各种复杂的分层，也不愿用简单的索引和SQL预处理提高性能，这里面其实是有问题的。
三、以我的经验，生产系统迁移数据库平台是非常罕见的事，没有必要为了非常小概率的数据库迁移问题放弃数据库层编程能力。
四、即使数据库编程只由DBA使用，一个功能强大的编程接口，也可以整个项目的运行和维护带来非常大的帮助。

 

 

2009-09-16

---

郑溪

---

发件人： 刘鑫

发送时间： 2009-09-16  09:50:04

收件人： Idea-Torrent; march.liu.blog; edb-china

抄送：

主题： [EDB-cn:6] 近日 twitter 发布信息整理

[Zoom.Quiet]

> 2009/9/16 刘鑫 <marc...@gmail.com>

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

这点非常认同:
data->SQL->存储过程...->ORM->业务逻辑
正是DB技术的不断发展才令业务逻辑不断远离数据的;-)
目的不是真正的远离，而是合理隔离，将精力聚集到核心问题上；
那么，隨着业务的不断演化，总是可以总结中非常固化的逻辑的，
这时，就应该将这部分业务，不断下沉到DB中...

--
http://zoomquiet.org 人生苦短? Pythonic!

Free as in Freedom! 哲思社区:http://zeuux.com