数据结构设计经验总结

前言

最近一年在公司作了大量的数据结构设计工做，目前对于设计工做也算驾轻就熟了。

在这里把本身在数据结构设计中的心得总结一下，方便本身查看，也方便与你们分享讨论。

 

 

正文

一、数据表必备元素

    目前我设计的数据表都会有四个必备元素id，建立时间，修改时间，删除标志。

    

 

二、数据的删除采用“假删除”方式

    项目中的删除功能只是改变删除标志（state），而不是直接delete掉。好处就是能够找到全部已经被删除的历史数据，也不怕用户误操做了，修改一下标志即可直接找回。

 

三、表关联“软硬适度”

    “软硬适度”这个词纯属本身发明，“硬关联”指的是存在外键关系的表关联，而“软关联”指的是保存对方id并无实质性的外建关系。这两种表的关联方式的运用智者见智，根据实际状况灵活运用，主要目的在于减小庞大表关系中的耦合度。个人习惯通常是同一业务模块的使用“硬关联”，而不一样业务模块的使用“软关联”。举个例子，用户模型中帐号表、权限表之间是“硬关联”，而帐号表和订单模型中的订单表使用“软关联”。

 

四、同一业务模块中的表命名使用相同的开头

   通常使用数据库client终端查看表时，都会采用按照字母顺序进行排序，表名开头相同的表都会聚在一块儿，在查找问题时很容易就能找到同一业务模块的一组表。例如店铺相关表以company开头，company_datum,company_person,company_level。而不要写成，datum_company,person_company,level_company。

 

五、表设计不能脱离代码实现

    设计表的时候必须思考代码实现，脱离实现的设计会给程序员带来困扰。个人作法通常都是先按照需求设计关系和字段。而后按照需求去思考每个功能应该怎样去写SQL。这样作的好处是在考虑了开发过程后，能比较清晰地知道数据表设计的是否合理，是否有必要增长一些冗余和辅助字段去简化开发工做。

 

六、注释是很重要滴（老生常谈）

    这实在是一个老生常谈的问题，学习任何开发语言老师都会不厌其烦的强调，公司领导也是磨破了嘴。可有些人依然我行我素不觉得然。固然也不是全部的状况都必须详细的写注释，详细程度也是和项目规模和复杂度决定的。一我的作一个简单的增删改查显然不必太较真。若是是一个公司不停迭代的产品那必要性就比较强了，主要有两点好处。 第一，若是项目要求不是太严格，注释写得好程序员能够直接看着需求原型和数据结构进行开发了。我有过四我的的项目组实践绝对没问题的。第二，当项目数据表达到百张以上，开发时间跨度大于一年，以前设计的东西回想起来就比较模糊了，有些时候要花很长时间去回忆当初的设计意图。

 

七、日志和记录表不要光记个id

    日志和记录表要直接记录结果数据而不要仅依赖于相关数据的id。日志和记录表是当时发生事件的留存，应该使用相似于快照的概念进行保存。若是仅使用id字段关联数据，当依赖数据被修改时将没法查看当时的状态。订单表中保存的商品数据是最典型的例子。

 

八、多对多中间表不要使用双主键

    有些朋友在建立多对多关联表的时候将，关联的两个字段设置为主键。这么设计的优缺点网上也有一些争议，可是大部分仍是建议不要这么作。我通常使用与业务无关的id做为主键。

 

九、要关心客户端开发习惯

     按理说数据结构设计中字段值的设定并不须要关心页面的展现顺序，至少在web开发是这样的。可是在客户端开发中若是值的顺序和展现顺序一致会给客户端开发人员带来一些便利。下面我举一个真实例子。

需求：客户端要展现一个多页签页面，可使用手势进行横向滑动。四个页签按顺序为 待接待、已接待、已完成、已取消。

客户端：使用了一款横向滑动组件进行开发

数据库：接待状态这个字段设计成int类型，而且值的顺序按照需求顺序排列  1-待接待、2-已接待、3-已完成、4-已取消。

    这个例子中若是数据库的值顺序与需求不一致，客户端就须要增长额外的判断来控制滑动组件。

 

其实还有不少须要注意的地方，一时想不起来，这篇博客我会一直补充修正的。