数据库设计实例要遵守哪些原则

    说到数据库设计实例，小编我头也是大大的，每次看到这一大堆的数值或者代码都能把人逼疯，都说做哪行都有哪行的规矩，数据库设计也是一样的，要遵守一定的规则才能完成，那么数据库设计要遵守哪些原则呢？下面就由小编来给大家简单的介绍下，希望能帮助大家在完成数据库的设计上面会有帮助。

    数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！

    那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：

    1、数据库设计最起码要占用整个项目开发的40%以上的时间

　数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。

    2、数据库设计不仅仅停留于页面demo的表面

　页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。

    3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了

　每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。

    4、数据库设计时就要考虑到效率和优化问题

　一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。

    5、添加必要的（冗余）字段

　像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。

    6、设计合理的表关联

　若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。

    7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联

　这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。

    8、选择合适的主键生成策略

　主键生成策略大致可分：int自增长类型（identity、sequence）、手动增长类型（建立单独一张表来维护）、手动维护类型（如userId）、字符串类型（uuid、guid）。int型的优点是使用简单、效率高，但多表之间数据合并时就很容易出现问题，手动增长类型和字符串类型能很好解决多表数据合并的问题，但同样也都有缺点：前者的缺点是增加了一次数据库访问来获取主键，并且又多维护一张主键表，增加了复杂度;而后者是非常占用存储空间，且表关联查询的效率低下，索引的效率也不高，跟int类型正好相反。

    终上所述，我们可见数据库设计在整个软件开发的起到的举足轻重的作用，尤其是我说的设计原则的第一点，数据库与需求是相辅相成的，我经常把软件开发比作汽车制造。汽车制造会经过图纸设计，模型制作，样车制造，小批量试生产，最后是批量生产等步骤。整个过程环环相扣，后一过程是建立在前一过程正确的前提基础之上的。如果在图纸设计阶段发现了一个纰漏，我们可以重新进行图纸设计，如果到了样车制造阶段发现这个错误，那么我们就要把从图纸设计到样车制造的阶段重来，越到后面发现设计上的问题，所付出的代价越大，修改的难度也越大。

    看完上面的数据库设计实例中的原则不知道对大家有没有帮助，数据库不必其他的一些，所以小编给大家介绍的这些是想让大家培养设计良好数据库的习惯，所以在今后的项目中大家一定要着重培养这方面的能力，这里我将我的经验分享给了大家，希望能对大家有所帮助。