数据库设计的问题

[linkinwhite]

我想问大家一个问题，数据库设计中基础信息表和单据的关联到底该如何设计为好？

第一种是不要冗余，基础表中存ID、Name...单据表中记录基础表的ID。
这种方法的问题，一是单据表的“历史性”如何保证，二是显示、查询时如果连接表过多会导致速度慢，三是基础表的删除如何控制（伪删除？）

第二种是适当冗余，基础表中存ID、Name...单据表中记录基础表的ID、Name。
当然存储空间增大了，但是减少表连接时间，能保证历史记录不变

第三种基础表中存ID、Name...单据表中记录基础表的Name

还有我看到一种就是基础表中只有一个字段Name


各位的项目里用的是哪种方式？我想请教一下

个人偏向于第二种，不过还有个小问题，比如某部门从“网络部”更名为“网络中心”，原来有个单子上部门名不改，还是“网络部”
那我现在查询“网络中心”，还列出以前“网络部”的单子吗？列出的话也就是根据ID来查询

[天-笑]

第二种好啊，方便维护

[王向飞]

第二种你在维护的时候就要顺带一起维护其他相关表了
看你是查询的多 还是更新的多

[billpu]

要看具体的业务关系,简单分析一下
我个人用第一种的比较多,
1 历史问题,不知道你的历史问题是指什么,是指基础表信息删除了,单据表的数据仍然没被删除?
解决办法,设计级联删除或者定义触发器,在基础表信息删除后,自动删除单据表的数据
2 显示查询时如果连接表过多会导致速度慢
首先连接的效率是很高,并没有比单表查询来的慢多少,而且这样你用来维护的成本低很多,比如记录增加的时候效率也可以快很多.
3 基础表的删除...
这个纯粹取决于你业务逻辑,一般是加一个tag,你在select的时候先过滤tag,当然你也可以使用视图,自动过滤tag后的数据,不过视图使用需要谨慎考虑

如果是第二种当然你后面提出的网络部和网络中心的问题也是存在的,但也不是没有办法解决,比如你可以定义触发器,基础表信息修改时,修改信息表与其相关联的内容

第三种...
没看懂...抱歉

[hao1hao2hao3]

第二种了，这可以叫做以空间换时间，哈哈！部门更改的时候可以建触发器进行同步，或者手工进行批量修改维护。

[linkinwhite]

“单据”这种东西录入以后可以再更改吗？

比如客户修改了送货地址，那他的历史订单的送货地址不能改成最新的，而是要保持当时的状态。比如客户修改了姓名，历史单据是应该存放他当时的姓名还是现在的姓名呢？

像一些基本的类别：如部门、入库类别、支付方式、送货方式等，如果更改的话应该还是要修订历史订单的吧？

[linkinwhite]

应该是录入并且审核以后，更改基础信息表的数据，那变化还会体现在单据上吗？

[linkinwhite]

[Quote=引用 3 楼 billpu 的回复:]
要看具体的业务关系,简单分析一下
我个人用第一种的比较多,
1 历史问题,不知道你的历史问题是指什么,是指基础表信息删除了,单据表的数据仍然没被删除?
解决办法,设计级联删除或者定义触发器,在基础表信息删除后,自动删除单据表的数据
2 显示查询时如果连接表过多会导致速度慢
首先连接的效率是很高,并没有比单表查询来的慢多少,而且这样你用来维护的成本低很多,比如记录增加的时候效率也可以快很多……
[/Quote]

我认为经过审核的历史数据都有分析的价值，怎么可能基础表信息删除后,就删除相关的单据表？我宁愿加删除标记

还有表连接，select * from A，和select A.* from A,B,C,D
比如A表有10000条记录，B,C,D各有100条
那这个select语句就要先做笛卡尔积出100亿条数据是吗？通过适当的索引会改善很多吗？我对这方面不太懂，求教

[cbgn]

我认为经过审核的历史数据都有分析的价值，怎么可能基础表信息删除后,就删除相关的单据表？我宁愿加删除标记
----那基础表伪删除。

还有表连接，select * from A，和select A.* from A,B,C,D
比如A表有10000条记录，B,C,D各有100条
那这个select语句就要先做笛卡尔积出100亿条数据是吗？通过适当的索引会改善很多吗？我对这方面不太懂，求
－－－－要有关联条件呀，索引会改善的，而且where能多筛的条件要放前面

[ggsysy]

用的是第一种，基础表中ID对应的name改变了，那么在单据表中的也会随着改变。因为单据表中只要调用ID，其相应的基础表中的信息就显示出来了。但是数据表里面只存储ID字段，只是在前台显示的时候可以看到而已，后台其他字段是没有的。不知道我说的清楚不？
关于查询查询速度，我觉得可以再做一张历史表，定时（比如1个月）结转数据到历史表，然后删除相应的当前表。