|
锁定老帖子 主题：数据库设计中的一些问题（讨论）
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-03
tianxinet 写道 以下是针对事务型数据库： 1.是否使用联合主键？个人倾向于少采用联合主键。因为这样会降低索引的效率，联合主键一般都要用到至少一个业务字段，往往是字符串型的，而且理论上多字段的索引比单字段的索引要慢些。看上去似乎也不那么清爽。 在实际的设计中，我尽量避免使用联合主键，有些时候“不得不”使用联合主键。 赞成! 引用 2.PK采用无意义的字段（逻辑主键）还是有意义的字段（业务主键）？个人倾向于“逻辑主键”，理由是这样设计出的数据库模型结构清晰、关系脉络清楚，往往更符合“第三范式”（虽然不是故意的，呵呵）。而且更容易避开“联合主键”，而且可以使用索引效率高的字段类型，比如int、long、number。缺点是用无意义的字段建立表间的关系，使跨表查询增多，效率下降。（矛盾无处不在，前面刚说完可以提高效率，这里马上又降低效率）。“业务主键”可以提升查询编码的简洁度和效率。 个人使用实际状况，总体来说“逻辑主键”比“业务主键”执行效率低，但不会低到无法满足需求。采用“逻辑主键”比采用“业务主键”更利于数据库模型的结构、关系清晰，也更便于维护。 对于分析型数据库，如数据仓库，千万不要这样做。 引用 3.不要使用多对多关系？个人倾向于少使用多对多关系。这个问题其实不是数据库设计的问题了，在数据库设计中，多对多关系也仅仅存在于逻辑模型（E-R）阶段，物理模型不在有多对多关系，实际数据库中也不会有“多对多”关系。这是使用ORM时的问题，比如使用Hibernate，多对多关系有时会使编码看起来灵活一些，代价是效率的明显降低。 个人实际使用中，设计时基本不考虑多对多关系，但编码时总会有小组成员使用一些多对多关系，自己建立多对多的ORM，使自己编码方便些，用在数据量小的地方，影响不大。大数据量，则“禁止使用”。 引用 4.为每个表增加一个state字段？我习惯在设计时给每个表设一个state字段，取值0或1，默认值为1，具体业务意义或操作上的意义可以自定义。可以作为一个状态控制字段，如查询、更新、删除条件，单据是否有效（业务单据对应的表会有业务意义上的“有/无效”或“状态”字段，这种情况下，我还是会再加一个state字段），甚至仅仅是控制一条数据是否“有效”（有效的意义你自己定）。在数据迁移（如转入分析用的数据库）时也可能会发挥作用。 引用 5.为每个表设置一些备用字段？没办法，我总是设计不出“完美”的数据表，给每个表加几个备用字段（我一般用字符串型，随你）可以应付“不时之需”，尤其是需要长期维护的、业务可能有临时性变动的系统。 引用 6.尽量不要在一个表中存入其关联表的字段？建议不存！这样做确实可以提高查询效率，但在一个有很多表，并且关联表多的情况下，很难保持数据的一致性！数据库结构也比较糟糕。而且不存，也不会使效率十分低下。 引用 7.不要去直接修改数据库？个人认为这点很重要，当需要修改时，应该先去修改模型，然后同步物理数据库，尤其是团队开发，否则要多做更多的事情来搞定，也可能会引入更多的错误。 |
| 返回顶楼 | |
|
发表时间：2006-03-03
tianxinet 写道 hanny0918 写道 不错，不过第6条“尽量不要在一个表中存入其关联表的字段？”楼主怎么解决两张表的关联？
另建一张表来当两张表的关联表？这样是否太麻烦一点？ 或者另有解决方法？ 不是指的外键。 比如“订单表”和“收货表”通过orderid建立关系，收货表中当然要存orderid这个字段，但尽量不要为了方便把“ordername”这个字段也存入收货表 |
| 返回顶楼 | |
|
发表时间：2006-07-27
为了不使篇幅拉的太长，就不全部引用原文了：
这是根据情况的, 一般说来,对于业务型表, 使用逻辑主键比较好,而对于公共基础表, 则使用业务主键比较好. >>一般是这样。（我曾接触过大型汽车制造集团的BOM，BOM对应到信息系统中就是基础表，一般我们说有“工艺BOM”、“生产BOM”，但是这里甚至还有一个“开发BOM”，承袭关系为“开发BOM”->“工艺BOM”->“生产BOM”，都是几十万以上的数据，从表的角度来看不算大表，但算是大的基础表，而且是分多层的（整车->总成->分总成->...->零件->材料，想想它涉及的面有多广），在国产化过程中所谓的“开发BOM”不断变动，导致“工艺BOM”，“生产BOM”也不断变动，这种情况还是使用逻辑主键比较好） 多对多关系是来自于逻辑模型, 但逻辑模型是物理模型的抽象, 谁所物理模型中不存在多对多关系呢? 在基于ORM的处理中,多对多关系往往是简化成双向的一对多关系(相对来说,多对多是复杂的). 是否禁止使用,更加在于模型的建立. >>当然，从抽象来说，物理模型中存在多对多。但既然已经从抽象到具体了，这里指的就是具体，就别抽象回去了 是个不错的主意,不过,一般留着做状态的字段更加建议使用字位数据,比如0,1,2,4,8,而不是简单的0和1. >>同意，这样更灵活 一个好的结构设置不在于备用字段,而在于扩展表. 备用字段始终都是有限并且类型固定的. >>我说的备用字段是不做“正式”用途的，在维护过程中、临时业务调整中可能会用到。 对于非流程性的业务,也就是数据模块相对独立的,楼主的建议不错,但是对于流程性的业务,如基于订单的MRP, 供应链等, 特定的业务信息,也就是业务字段最好能够存在于相应的后续表中, 光关注结构而忽略效率并不是一个可取的方式. >>这是一对矛盾，我觉得衡量的最恰当标准是性能、资源消耗情况，矛盾突出的时候最好的办法是在搭建模拟运行环境实测。根据实测情况选一个“性价比”比较好的方案。 在订单中,业务主键是订单编号,orderNo, 我不清楚对应楼上的名称还是id, 不过正如我前面说的,对于业务类型表,使用逻辑主键比较好些. 但是需要注意的是, 关联的含义有两种,一种是直接表的关联,一种是经过多层关联建立的间接关联. 对于前者,楼主的建议是对的,但对于后者, 就不一定了. 往往在实际系统中是需要牺牲结构来换取效率的. >>没错，牺牲结构换效率的事经常做，牺牲效率换结构的事也没少做，呵呵 |
| 返回顶楼 | |
|
发表时间：2006-07-31
关于联合主键
我想到一个方法 可以用equlse方法来使用 将两到三个应该联合的字段用equlse包装起来 不知这种作法合不合理有没有必病 |
| 返回顶楼 | |
|
发表时间：2006-08-16
表间关系最好不要存在闭合环（不是指回路），否则表间关系的操作会很复杂
|
| 返回顶楼 | |
|
发表时间：2006-09-04
liu_w_j 写道 表间关系最好不要存在闭合环（不是指回路），否则表间关系的操作会很复杂
因该不会有人这么设计吧 |
| 返回顶楼 | |
|
发表时间：2006-09-04
hasi 写道 liu_w_j 写道 表间关系最好不要存在闭合环（不是指回路），否则表间关系的操作会很复杂
因该不会有人这么设计吧 很有可能这样。比方说一个父对象有多个子对象，而且一个经常需要的操作就是得到父对象的第一个子对象。那么很可能产生下面的设计：
table parent
id
first_child_id
table child
id
order_id
parent_id
这样就产生了闭合环。当然这是一个不好的设计，宁可多做一次查询。 |
| 返回顶楼 | |
