数据库设计中的一些问题（讨论）

前提声明，个人观点：

没有最好的，只有最合适的。
对不同的视角，所谓的“最合适”也是不同的。
设计总是伴随者“妥协”的。

请不要在讨论中试图证明个人的观点是“最好的”。

大家都提出自己的经验、思路、教训等等，让参与讨论的人根据自己的条件（这个我们无法完全为他人设想），有所取舍的得到“我所正需要的”。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

以下是针对事务型数据库：
1.是否使用联合主键？个人倾向于少采用联合主键。因为这样会降低索引的效率，联合主键一般都要用到至少一个业务字段，往往是字符串型的，而且理论上多字段的索引比单字段的索引要慢些。看上去似乎也不那么清爽。
在实际的设计中，我尽量避免使用联合主键，有些时候“不得不”使用联合主键。

2.PK采用无意义的字段（逻辑主键）还是有意义的字段（业务主键）？个人倾向于“逻辑主键”，理由是这样设计出的数据库模型结构清晰、关系脉络清楚，往往更符合“第三范式”（虽然不是故意的，呵呵）。而且更容易避开“联合主键”，而且可以使用索引效率高的字段类型，比如int、long、number。缺点是用无意义的字段建立表间的关系，使跨表查询增多，效率下降。（矛盾无处不在，前面刚说完可以提高效率，这里马上又降低效率）。“业务主键”可以提升查询编码的简洁度和效率。
个人使用实际状况，总体来说“逻辑主键”比“业务主键”执行效率低，但不会低到无法满足需求。采用“逻辑主键”比采用“业务主键”更利于数据库模型的结构、关系清晰，也更便于维护。
对于分析型数据库，如数据仓库，千万不要这样做。

3.不要使用多对多关系？个人倾向于少使用多对多关系。这个问题其实不是数据库设计的问题了，在数据库设计中，多对多关系也仅仅存在于逻辑模型（E-R）阶段，物理模型不在有多对多关系，实际数据库中也不会有“多对多”关系。这是使用ORM时的问题，比如使用Hibernate，多对多关系有时会使编码看起来灵活一些，代价是效率的明显降低。
个人实际使用中，设计时基本不考虑多对多关系，但编码时总会有小组成员使用一些多对多关系，自己建立多对多的ORM，使自己编码方便些，用在数据量小的地方，影响不大。大数据量，则“禁止使用”。

4.为每个表增加一个state字段？我习惯在设计时给每个表设一个state字段，取值0或1，默认值为1，具体业务意义或操作上的意义可以自定义。可以作为一个状态控制字段，如查询、更新、删除条件，单据是否有效（业务单据对应的表会有业务意义上的“有/无效”或“状态”字段，这种情况下，我还是会再加一个state字段），甚至仅仅是控制一条数据是否“有效”（有效的意义你自己定）。在数据迁移（如转入分析用的数据库）时也可能会发挥作用。

5.为每个表设置一些备用字段？没办法，我总是设计不出“完美”的数据表，给每个表加几个备用字段（我一般用字符串型，随你）可以应付“不时之需”，尤其是需要长期维护的、业务可能有临时性变动的系统。

6.尽量不要在一个表中存入其关联表的字段？建议不存！这样做确实可以提高查询效率，但在一个有很多表，并且关联表多的情况下，很难保持数据的一致性！数据库结构也比较糟糕。而且不存，也不会使效率十分低下。

7.不要去直接修改数据库？个人认为这点很重要，当需要修改时，应该先去修改模型，然后同步物理数据库，尤其是团队开发，否则要多做更多的事情来搞定，也可能会引入更多的错误。

基本上同意楼主的观点，
还有我们一般在每个表加 创建记录时间，创建记录人，修改记录时间，修改记录人 四个字段的。

我也基本上也同意搂主的，但是第5点一般我不会留备用字段，假如备用字段增加多了，也需要空间保留呀，会对数据库造成影响的，再说了如果需要增加字段的话我们可以临时加入，也不会影响以后的维护，对系统也不会造成影响。

我觉的修改记录时间，修改记录人一般不需要，你只是保存当前修改的人，如果下一个人人修改该条记录，就把前面的覆盖了；
创建记录时间，创建记录人这个看表的情况而定，如果不是重要的表，我觉的没有必要加。

不错，不过第6条“尽量不要在一个表中存入其关联表的字段？”楼主怎么解决两张表的关联？
另建一张表来当两张表的关联表？这样是否太麻烦一点？
或者另有解决方法？

当然只记录当前修改的人和时间了，因为以前修改的都无效阿，数据库里也没有历史记录

在没个表中增加一个精确到秒的时间戳字段，新增、修改时都设置新的值，在跟踪BUG太方便了

我一般
还经常有的两个字段

一个是DOMAIN
还有一个是STAMP(时间戳)

加上Domain是因为我做的一些东西如权限
经常被多个系统使用
而且有时候有些表单的东西也用到DOMAIN

我一般使用如下的组织机构设计，在组织机构中增加一个内部码
1  总公司
  101 分公司
   10101 分公司部门

很多业务实体如果属于某一个部门，不是用部门表的主键去关联，而是直接使用内部码，这样可以方便的检索各级机构范围的数据

不是指的外键。

比如“订单表”和“收货表”通过orderid建立关系，收货表中当然要存orderid这个字段，但尽量不要为了方便把“ordername”这个字段也存入收货表