mysql数据库开发的经验教训

angela

1、数据库设计需要在深入理解需求之后，确定设计方案，并详细考虑到实现每一个功能的实现思路。在开始代码前最好将数据库确定了，本次失误：由于需求改变及初期设计不完善两个原因导致中期连续的更新数据库。引起团队开发人员的反感和郁闷。
2、数据命名需要建立一个统一的命名规则。个人选择的一套规则：
a)数据库表的命名以是名词的复数形式且都为小写，如cities, categories, friends等等
i.如果表名由几个单词组成，则单词间用下划线("_")分割，如subscribed_pois,poi_categories等
ii.表名尽量用全名
iii.表名限制在30个字符内。当表的全名超过30字符时，可用缩写来减少表名的长度，
b)字段名为小写
i.字段名为有意义的单词，或单词的缩写
ii.如果字段由几个单词组成，则单词间用下划线("_")分割，如client_id，post_code等
iii.字段名限制在30个字符内。当字段名超过30字符时，可用缩写来减少字段名的长度，如description --> desc；information --> info；address --> addr等
c)主键、外键命名规则
i.主键按照PK_<table>的规则命名，其中<table>为数据库表名
ii.唯一键按照UK_<table>_<column>的规则命名，其中<table>为数据块表名，<column>为字段名
iii.外键按照FK_<pppp>_<cccc>_<nn>的规则命名，其中<pppp>为父表名，<cccc>为子表名，<nn>为序列号
d)索引命名规则
i.索引须按照IDX_table_<column>_<column>,其中<table>是建立索引的表名，<column>是建立索引的字段名
ii.索引名限制在30个字符内。当索引名超过30字符时，可用缩写来减少索引名的长度，如description --> desc；information --> info；
3、数据库引擎的选择，使用mysql的数据库的都知道，mysql数据库有10种左右的数据库引擎，每种的特点各不相同。这里数据库主要用来查询、修改和更新数据的。因此我们选择使用innodb引擎。【我对各个引擎并不是十分了解，只是大概记得innodb适合应用于数据修改查询频繁的场景，MyISAM比较适合用来做数据分析使用，具体选择各位针对自己应用特点查询选择】
4、数据库编码设置，由于我们是中文网站，我们将数据库的编码统一设置成utf-8格式。这个也是根据个人选择吧，其实应该可以选择gbk的。
5、数据库设计工具，我使用的设计建模工具是PowerDesigner。用过之后感觉确实简单易用。
6、数据库设计时需要注意问题。
     数据库结构争取一次到位，也就是数据库有多少张表，各个表之间的关系时应该考虑周全避免修改，尤其应当避免下面情况的发生：在写实现代码逻辑时才发现现有的数据库设计无法实现或者实现很麻烦的情况。出现这样的情况是数据库设计的缺陷，也容易影响开发者的士气，因为此时数据库结构上的修改以为着需要修改大量的相关代码。建议宁愿晚开工写代码也要多花时间详细分析数据库结构设计是否能满足功能的需求。【当时我们过这个功能需求时，就有些粗心导致后期修改，非常影响士气，大家应该知道程序员是最懒的一种人群。】
    表的设计，确定数据库建模时表的基本属性列，对于部分非基础信息属性可以后期设计时再添加，这个修改起来影响相对较小。当然如果能够一次全部确认最好。Varchar长度的选择在满足条件的情况下最好选择字节的整数倍。
    添加适当冗余数据，并不是满足第三范式的数据库是最好的，相反在数据库的中添加适当的冗余数据，会有很多好处这个看自己的分析和需要。比如我在users表中添加了friend_num,fan_num,blog_num统计数据列。这样在查询用户信息时，就不需要对用户关系表和博客表做统计查询操作。统计数据的修改可以使用触发器来实现。
     拆分表格，当一张表包含的数据列较多时，可以将一张表拆分为两张表。拆分原则是将经常使用【查询和修改】数据列放在一张表里，而相对变化较少的数据放在了另一张表中。比如我将users表拆分成users和user_infos两张表，users中存储的是经常查询或修改的数据信息，而user_infos表中存储的则是相对较少使用或者可以为空的数据。
    建立合适的索引，索引不是越多越好，视需要建立
7、记录数据库修改内容和时间：每当需要修改数据库时，最好能够记录修改的内容【表结构，列属性，存储过程，触发器等等，当然如果能够记录修改原因更好】，命名的时候用时间来命名。