前言
最近一年在公司做了大量的数据结构设计工作，目前对于设计工作也算得心应手了。
在这里把自己在数据结构设计中的心得总结一下，方便自己查看，也方便与大家分享讨论。
正文
1、数据表必备元素
目前我设计的数据表都会有四个必备元素id，创建时间，修改时间，删除标志。
2、数据的删除采用“假删除”方式
项目中的删除功能只是改变删除标志（state），而不是直接delete掉。好处就是可以找到所有已经被删除的历史数据，也不怕用户误操作了，修改一下标志便可直接找回。
3、表关联“软硬适度”
“软硬适度”这个词纯属自己发明，“硬关联”指的是存在外键关系的表关联，而“软关联”指的是保存对方id并没有实质性的外建关系。这两种表的关联方式的运用智者见智，根据实际情况灵活运用，主要目的在于减少庞大表关系中的耦合度。我的习惯一般是同一业务模块的使用“硬关联”，而不同业务模块的使用“软关联”。举个例子，用户模型中账号表、权限表之间是“硬关联”，而账号表和订单模型中的订单表使用“软关联”。
4、同一业务模块中的表命名使用相同的开头
一般使用数据库client终端查看表时，都会采用按照字母顺序进行排序，表名开头相同的表都会聚在一起，在查找问题时很容易就能找到同一业务模块的一组表。例如店铺相关表以company开头，company_datum,company_person,company_level。而不要写成，datum_company,person_company,level_company。
5、表设计不能脱离代码实现
设计表的时候必须思考代码实现，脱离实现的设计会给程序员带来困扰。我的做法一般都是先按照需求设计关系和字段。然后按照需求去思考每一个功能应该怎样去写SQL。这样做的好处是在考虑了开发过程后，能比较清晰地知道数据表设计的是否合理，是否有必要增加一些冗余和辅助字段去简化开发工作。
6、注释是很重要滴（老生常谈）
这实在是一个老生常谈的问题，学习任何开发语言老师都会不厌其烦的强调，公司领导也是磨破了嘴。可有些人依然我行我素不以为然。当然也不是所有的情况都必须详细的写注释，详细程度也是和项目规模和复杂度决定的。一个人做一个简单的增删改查显然没必要太较真。如果是一个公司不停迭代的产品那必要性就比较强了，主要有两点好处。 第一，如果项目要求不是太严格，注释写得好程序员可以直接看着需求原型和数据结构进行开发了。我有过四个人的项目组实践绝对没问题的。第二，当项目数据表达到百张以上，开发时间跨度大于一年，之前设计的东西回想起来就比较模糊了，有些时候要花很长时间去回忆当初的设计意图。
7、日志和记录表不要光记个id
日志和记录表要直接记录结果数据而不要仅依赖于相关数据的id。日志和记录表是当时发生事件的留存，应该使用类似于快照的概念进行保存。如果仅使用id字段关联数据，当依赖数据被修改时将无法查看当时的状态。订单表中保存的商品数据是最典型的例子。
8、多对多中间表不要使用双主键
有些朋友在创建多对多关联表的时候将，关联的两个字段设置为主键。这么设计的优缺点网上也有一些争议，但是大部分还是建议不要这么做。我一般使用与业务无关的id作为主键。
9、要关心客户端开发习惯
按理说数据结构设计中字段值的设定并不需要关心页面的展示顺序，至少在web开发是这样的。但是在客户端开发中如果值的顺序和展示顺序一致会给客户端开发人员带来一些便利。下面我举一个真实例子。
需求：客户端要展示一个多页签页面，可以使用手势进行横向滑动。四个页签按顺序为 待接待、已接待、已完成、已取消。
客户端：使用了一款横向滑动组件进行开发
数据库：接待状态这个字段设计成int类型，并且值的顺序按照需求顺序排列 1-待接待、2-已接待、3-已完成、4-已取消。
这个例子中如果数据库的值顺序与需求不一致，客户端就需要增加额外的判断来控制滑动组件。
其实还有很多需要注意的地方，一时想不起来，这篇博客我会一直补充修正的。
1553
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
