数据库开发性能设计

 

数据库开发性能设计

鉴于开发人员一般情况下都是从头做到尾,也就是说从界面到业务逻辑开发,到SQL编写,到表的建设,数据的模拟测试. 在工期短,需求变更频繁情况下,性能就会成为了牺牲品.优化就日后再说,如同 www.12306.cn网站样!

1 分工篇

  如同网站开发有美工搞CSS代码,HTML代码样,NET和JAVA程序员应该把SQL语句全部交给数据库开发工程师写.可惜这不过是理想状态而已. 很多的时候都是程序员写代码同时连带把SQL也写了.!

如何解决? 其实很简单，所有的SQL都做成视图，也就是VIEW。什么SUM() GROUP BY WHERE 语句 统统做成视图  程序员可以继续写SQL， 或许简单,或许复杂,或许糟糕。不要紧.做成了视图就行了.业务代码就从视图里获取些数据就可以了! 就一个简单的SQL  比如

select rcdate,usernuber from vw_active_user;

  那个性能问题怎么办? 做成了视图,日后发现性能问题,则可以交给DBA去优化。DBA去优化视图,重写视图里的SQL语句,做起来就简单方便了。不再需要跟程序员去沟通,协调,强逼,投诉,无奈等时间成本，顶多向程序员了解下业务逻辑.。若DBA忙,也可以交给数据库开发工程师去优化重写。

 

2 读写分离

  当个项目运行很久,发现数据量大增,用户大增.后台数据库有点吃不消。

DBA想把读取业务和写入业务分开了。等他于程序员沟通后发现其实这是件不可能完成的任务.难道很困难吗？因为业务代码都是混合行的。比如www.12306.cn 差不多是混合型的.

你查火车票,然后去下单. 那么简单的业务.包含了读取,然后下单,写入业务.从代码来看就是SELECT和UPDATE 两类操作最多.那怕 ORACLE RAC集群上百台机器去堆,才会有些性能提高，只不过是杯水车薪。因为ORACLE RAC 是机器内存融合在一起的，互相之间内部通讯,协调开销猛增.

 其实很简单,就开始稍微麻烦点 项目开发的时候,后台数据库搞两帐号一个是只读帐号,另外个是只写帐号. 两帐号的表分别独立. 两个帐号的数据同步就由DBA或者是数据库开发师负责。这样一来，做集群,做机器分布就容易多了!

 

3 数据驱动

 所谓数据驱动啦! 就是业务增加某个东西的时候,不需要改JAVA代码,也不需要改SQL.

比如说一个网站项目涉及全国31省的数据.如果没有把省作为驱动地话，或者认为我们国家就31个省。

如果有一天,台湾回归了,成为了第32个省,香港被提升为省级,第33个省，这都是有可能的。

这时候我们发现有些程序要改代码. 因为程序里面包含类似的代码：for int i=1 to 31

像这样隐藏的代码估计很多，要从汪洋般代码里找出来修改。修改的人力和时间成本高，

而且还没有成就感，另外要进行大量地测试来保证质量，还有提心吊胆地上线，发现某个异常白发又长一根。

  比如 代码和SQL里的尽量不要有 字符，数字等内嵌的。这些由用户从页面上输入，或者由后台维护进某个表。除了一般的字典表外，应该建立个下面格式的表

ID

TABLE_NAME

CLOUMN

VALUE

MEMO

100086

T_provcode

PROVCODE

81

电信

 

Select * from  t_Active_user

where  recdate=:bind_date

and provcode=(select value from  t_dirction where id = 100086)

 

代码里只有一个10086 内嵌的数字

 

4 业务代码放哪里?

 按照JAVA流行趋势,业务代码应该放在中间件中,由JAVA代码完成.从而使得业务独立于数据库。不过JAVA流行以来，用纯JAVA写业务代码，感觉运行缓慢。记得05年初在一家电力设备厂，为电力网开发项目，JAVA组和NET组发生了冲突。老板会上说了JAVA不是，因为代码跑得慢，害得客户购买IBM机器还是那么不尽人意！ 据说国内某个大的ERP软件，鼓吹JAVA中间件如何如何的好。不知发现新版ERP系统还有很多业务放在数据库端的存储过程。业界视乎存在这样的看法要么把业务放在中间件上，要么放在数据库端的存储过程上。 JAVA那 HIBRATE 把数据库当作数据存放的地方,把数据全取到中间服务器上,然后一级,二级缓冲.再搞个HQB的查询语言来优化性能.. 这就是JAVA慢的原因所在

在下认为，业务代码放在中间服务器上是必须的，那数据库端也要有存储过程， 这是为了性能！

数据库端放的是数据代码,以前C/S架构的业务代码和数据代码混合在一起,都放在数据库端,由SQL语句去实现.那么到了B/S架构应用,就该把业务代码分离出去,数据库端就存放数据代码,由存储过程的SQL实现.

  什么是数据代码呢? 数据从表里取出来后,要做过滤,汇总等不涉及业务规则的代码。比如拿火车购票网来说，它什么时候把票放出来是业务代码。查询某个时间，某站到某站的火车列表，席位，票数，以及票价，这是数据代码。一张身份证只能购买同天同一车次的一张票，这也是业务代码。登录时间从6点到23点，付款时间是45分钟，一个人一次购买5张火车票。

 只要分清了业务代码和数据代码，就容易了。业务放在中间服务器上，数据代码放在数据库服务器上。业务规则独立和性能都得到均衡！

  JAVA做面向对象设计时，做出来的实体对象，其属性要存储，不能直接转换成物理表。 转换成物理表要交给数据库专家设计，数据库专家拿到实体对象表根据3N方式和经验转换成逻辑表。DBA专家拿着逻辑表转换成物理表。

 一个团队组成：项目经理，需求专家，业务设计专家，业务开发工程师，数据库专家，数据库开发工程师，开发DBA，测试工程师。

很多项目组是凑不了那么多人手，而且为了追求开发速度，基本构成 项目经理，开发工程师，测试工程师。这样性能就得不可能很好！采用上面4个策略，可以说发现了性能问题，改起来就容易多了。

 

 5 表设计

   表设计如果是事务型基本遵循3N范式. 如果是分析型是合并型. 这点没什么可说. 有点是数据行之间关系还有时间的关系

  行的关系 实际上行与行之间是没有关系的,  不过从另外个角度来说,或者是JAVA用每行来构成对象来说.

 比如说 男学生表里面插入了女学生的信息进去,虽然可以用个标志字段SEX来区别.

  如果只是把数据放进表很少拿出来用的话,那就无所谓了呀,什么性能都是空话!

 性能就是把里面的数据拿出来用,嫌弃它太慢!

 表设计来说 我们应该遵循标准

 1 业务标准  把不相关的业务数据不要放在一起, 无论理解起来都很吃力. 不要面向服务器,程序流程来命名表

 2 把不相关的数据 独立开了,存放在另张表里. 比如 男女生,比如联系人表中被删除的联系人.

 3 根据实际情况采用3N范式部分