数据库表结构设计规范-浅谈，为啥是浅谈呢，因为主要的观点还是来自原微信公共账号的一篇文章，稍微加了一些自己的看法。
谁来进行数据库的设计？
肯定是具体的开发工程师来进行，开发同学的话，第一业务熟悉度比较高，第二结合OO和ORM的思想，能有比较好的运用关系型数据库的特性。如果是DBA同学的话，虽然对于数据库本身了解比较多，但是对于业务了解较少，很难有比较客观的设计。但是业务上线或者运行期间，需要DBA同学能够重度的加入进来，针对一些性能点和不合理的点进行优化，同事也可以在上线前，针对SQL进行review，在萌芽阶段，就杜绝掉高危的SQL。这样的协作，应该会比较高效。
关系型数据库之父总结的12条规则是什么（找了几条有用的列举了一下）？
信息法则 关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
保证访问法则 依靠表名、主键值和列名的组合，保证能访问每个数据项（这一条其实是数据库表的可读性约束）。
空值的系统化处理 支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。
数据的物理独立性 不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
数据的逻辑独立性 当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。
数据完整性的独立性 专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
分布独立性 不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
数据库中到底要不要搞触发器等逻辑？
在应用系统的划分中，应用系统用于编写业务逻辑，承载所有的业务逻辑，然后数据库用来持久化数据，同时提供查询功能，这时候如果有业务逻辑冗余在数据库中，一来数据库干了他不擅长的事情，二来业务逻辑比较分散，导致后续的维护成本变大，如果数据库就是存数据的系统，那就让他尽量保持单一吧。
那些数据不适合放在关系型数据库中？
1、图片后者文件，不适合放在关系型数据库中，可以找第三方存储介质，然后数据库中存储路径即可；
2、临时性的数据或者生命周期很短的数据，例如web应用中的session数据，存活周期很短，没有必要在数据库中持久化存储；
3、日志文件等信息，日志文件保留，对于系统运行的可追溯和可回溯，起到很大的作用，但是不适合保存在数据库中，可以把日志的分析结果或者统计计算进行保留；
数据库中的列的顺序，怎么样比较好？
列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
关于范式和反范式，怎么样比较好？
范式的规范说明，每个字段只包含最小的信息属性，同时模型含有主键，非主键字段依赖主键，模型非主键字段不能相互依赖。
范式化模型的好处在于数据没有冗余，更新非常容易，缺点就是多模型Join的情况下，性能会有问题。
反范式模型的有点在于数据在存储层面有很好的可读性，确定是更新需要维护冗余数据。
范式设计的目的，在于消灭重复数据，避免编写不必要的，用来使重复数据同步的代码，保持表的瘦身，以及减从一张表中读取数据时需要进行的读操作数量， 最大化聚集索引的使用，从而可以进行更优化的数据访问和联结，减少每张表使用的索引数量，因为维护索引的成本很高。
数据库主键，是采用自增还是系统指定的逻辑？
这个可以根据业务场景进行，在大多数情况下使用数据库的自增作为主键，问题不大，但是如果面临分库分表的情况想，这时候就需要有一定的逻辑了，例如同一个表，00和01连个物理表，数据库的主键，是不能重复的。另外，每张表都需要有一个对用户而言有意义的自然键，在特殊情况下也许找不到这样一个项，此时可以使用复合键。这个键在程序中并不会使用其作为唯一标识，但是却可以在对数据库直接进行查询时使用。这样系统生成加业务含义两个结合，在系统和业务设计上做了权衡。
数据库的外键，是仅仅在应用系统中维护，还是数据库层面做强校验（来自知乎：mysqlops）？
外键是否采用看业务应用场景，以及开发成本的，大致列下什么时候适合，什么时候不适合使用：
1. 互联网行业应用不推荐使用外键： 用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；若是把数据一致性的控制放到事务中，也即让应用服务器承担此部分的压力，而引用服务器一般都是可以做到轻松地水平的伸缩；
2.传统行业
1>.软件应用的人数有限，换句话说是可控的；
2>.数据库服务器的数据量也一般不会超大，且活跃数据有限；
综合上述2句话描述，也即数据库服务器的性能不是问题，所以不用过多考虑性能的问题；另外，使用外键可以降低开发成本，借助数据库产品自身的触发器可以实现表与关联表之间的数据一致性和更新；最后一点，使用外键的方式，还可以做到开发人员和数据库设计人员的分工，可以为程序员承担更多的工作量；
如何结合业务场景去做数据库设计？
常见的业务场景，可以列举如下，
1、这个表结构是否是核心业务数据，是核心还是过程性的，这决定了对于这个表的关注情况；
2、数据库表的读写情况，以及读写的比例情况；
3、数据总量情况以及增量情况，例如每天新增多少数据，保存过去多少天的数据；
4、数据的散列情况，列入数据表字段很多，但是一条记录中有数据的列不多，或者是全部都有，这种都会影响到性能情况；
如何提升insert的效率？
1、可以考虑使用多值插入，类似这种形式，insert into XXX_table() values(),(),()，但是要注意SQL语句形成文本的大小不要超过数据库的限制；
2、提交事务，可以批量提交，例如如果ORM框架使用的是iBatis，可以考虑使用batchInsert功能，这样的SQL语句是分开的，但是提交是一次性的；
3、总体，就是减少和数据库之间的交互，避免没必要的网络开销；
PS：
参照信息来自公众账号信息如下
『数据库开发』分享 数据库 相关技术文章、工具资源、精选课程、热点资讯，欢迎关注。微信号：{ DBDevs }
http://iamzhongyong.iteye.com/blog/2192178