[讨论]多个窄表好还是单个宽表好

jxwangjm 2008-01-22 03:19:14


举个例子,一个物料基本档中,包含很多栏位,其中有些栏位
只能由生管编辑,有些由工程编辑,对于这种情形,是设计成一个表好,
还是多个表。MS SQL2000的帮助上说多个窄表好。我分析起来各有优缺点如下:
1、使用多个表的话,那么如果要抓两个表的资料时,势必使用交叉查询,这肯定
没有单个表速度快。
2、在编辑时,使用单个表引起的锁定比多个表要多。
3、如果要进行表一级的访问权限控制的话,使用多个表肯定比单个表要好。不过,
表一级的访问权限控制这个功能我在实际中没有使用,我们公司的ERP也没有使用这
一点,这个功能用得到的公司应该不多。

希望大家指点一下,谈谈自己的做法。
...全文
2554 39 打赏 收藏 转发到动态 举报
写回复
用AI写文章
39 条回复
切换为时间正序
请发表友善的回复…
发表回复
jch_jch 2009-07-17
  • 打赏
  • 举报
回复
数据仓库大多使用宽表(用于数据挖掘),一般的数据库大多使用窄表(基于范式)
magic6321 2008-11-13
  • 打赏
  • 举报
回复
收获...
jxwangjm 2008-01-24
  • 打赏
  • 举报
回复
自个再顶一下
rockyvan 2008-01-24
  • 打赏
  • 举报
回复
我也同意多表好,因爲我曾經就被害慘過一次。
數據關係不是很複雜的時候,體現不出來,多了複雜了就明顯了。
ydlchina 2008-01-24
  • 打赏
  • 举报
回复
顶顶
rouqu 2008-01-24
  • 打赏
  • 举报
回复
商业销售的信息系统,发票信息,客户信息,发票信息表中如果只有一个客户ID的话,如果,后来修改了该客户的名字,以后重新打印该顾客的购物发票时,会和原先出具的发票不同(顾客名称已经变成了新名称)的情况.
---------------------
这种情况 是不好直接对数据做更新的 根据需要保存多条记录
jxwangjm 2008-01-24
  • 打赏
  • 举报
回复
那也是相对的,客观的标准?
-------------------------------------------
我知道没有绝对客观标准,但是来讲,需要考虑哪些事项还是有一定准则
ojuju10 2008-01-24
  • 打赏
  • 举报
回复
具体看业务逻辑和需求吧,不能笼统地回答
-狙击手- 2008-01-23
  • 打赏
  • 举报
回复
那也是相对的,客观的标准?
cxmcxm 2008-01-23
  • 打赏
  • 举报
回复
Haiwer(海阔天空):
“一般情况,应该保持设计的对象与客观存在保持一致。”
反对因为其他(非客观原因)原因认为拆分
----------------------
非常同意!如果维护与使用起来不方便,又何尝不是另一种低效率.
中国风 2008-01-23
  • 打赏
  • 举报
回复 1
合理的拆分要有针对性,方便以后软件的扩展和升级。。
设计太死了,以后升级系统只有完全重新来。这种情况要避免
r_swordsman 2008-01-23
  • 打赏
  • 举报
回复
太窄也不好...太宽也不好....
按不同的用途分开最好了....
gfgen 2008-01-23
  • 打赏
  • 举报
回复
我的感觉,设计数据库应符合范式规定,否则会对数据库的一致性和维护性带来很大的麻烦,但是,我们也不能完全符合范式规定,应为有些重要信息在某些表中数据被修改后无法再次还原,对于数据变化缓慢,且查询统计汇总多的表也不要过分注重范式规定,否则查询汇总的速度会出问题,而不在与大表小表.
例如:
商业销售的信息系统,发票信息,客户信息,发票信息表中如果只有一个客户ID 的话,如果,后来修改了该客户的名字,以后重新打印该顾客的购物发票时,会和原先出具的发票不同(顾客名称已经变成了新名称)的情况.
对于经常需要汇总的数据可将他们按月提交到已结算表中,并且将合计金额字段放在表中(不符合范式,当然可以用索引视图),但是这样就能极大的提高检索效率,
因此,我认为,数据库的设计,应对经常变化的数据使用较小的表,并尽量符合范式,免得出现错误,而对于陈旧的数据(通过结算报表等手段),转移到大表中,并不要顾忌范式的规定,已提高查询速度为主,多用索引.当然也要根据客户的要求来定.如数据量不大也不必考虑这么多.
昵称被占用了 2008-01-23
  • 打赏
  • 举报
回复
话是这么说的,不过我强调的是“一般情况,应该保持设计的对象与客观存在保持一致。”
反对因为其他(非客观原因)原因认为拆分
jxwangjm 2008-01-23
  • 打赏
  • 举报
回复
按照搂主的描述,只是因为权限(由哪些人编辑)引起考虑分表,而实际的个字段代表的属性是属于一个对象的,这种情况拆分开就会人为的制造出虚拟的对象,所以个人认为不拆分的好。

--------------------------------------
这个我倒觉得不是一个问题,在对象模型中,也可以相应的分成多个对象,对象与属性之间本然就没有严格的界限
jxwangjm 2008-01-23
  • 打赏
  • 举报
回复
多谢大家的指点,对这个问题有了更进一步的看法
昵称被占用了 2008-01-23
  • 打赏
  • 举报
回复
按照搂主的描述,只是因为权限(由哪些人编辑)引起考虑分表,而实际的个字段代表的属性是属于一个对象的,这种情况拆分开就会人为的制造出虚拟的对象,所以个人认为不拆分的好。

这不是个范式的问题,因为不涉及依赖关系,而是个对象是否拆分的问题,一般情况,应该保持设计的对象与客观存在保持一致。

权限问题可以考虑用视图来解决

个人观点
-狙击手- 2008-01-23
  • 打赏
  • 举报
回复
3NF

主要还是看项目,因时因地而宜
SeerMi 2008-01-23
  • 打赏
  • 举报
回复
支持窄表,类似面向对象的思路

把问题拆分,缩小,这样操作和维护都是有好处的
dobear_0922 2008-01-23
  • 打赏
  • 举报
回复
先建一个宽表,再根据需要分出几个窄表
加载更多回复(19)

34,588

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧