110,538
社区成员
发帖
与我相关
我的任务
分享数据字典设计问题
在系统设计过程中，发现系统中存在大量的自动表，其结构非常的相似。考虑用一个表设计，但是同事说一个表看的不明白。我认为在数据库中统一字典表是有意义的。
主要观点为虽然每个字典意义不同，那表现在对人的理解上，但结构对程序来说是重复，从重构的角度的来说，放在一块比较好。
可是换种角度，如果是分表设计，也可以在程序设计时所有的字典的维护用一套程序。
字典设计到底是多表存储好还是单表存储好，综合考虑后，个人认为单表大一点，希望各位给个建议。
主要观点为虽然每个字典意义不同，那表现在对人的理解上，但结构对程序来说是重复，从重构的角度的来说，放在一块比较好。
可是换种角度，如果是分表设计，也可以在程序设计时所有的字典的维护用一套程序。
字典设计到底是多表存储好还是单表存储好，综合考虑后，个人认为单表大一点，希望各位给个建议。
...全文
请发表友善的回复…
发表回复
boringame 2009-12-03
- 打赏
- 举报
逻辑上两种都可以，
但这个怎样好呢。。。
还真没个准，
说以我就主观意见了。。
但这个怎样好呢。。。
还真没个准，
说以我就主观意见了。。
thinkc 2009-11-16
- 打赏
- 举报
自己路过
thinkc 2009-11-13
- 打赏
- 举报
顶上去
boringame 2009-11-12
- 打赏
- 举报
我的的主观意见是放在一起。。。
表一大堆看的就很烦。。。
表一大堆看的就很烦。。。
wuyq11 2009-11-12
- 打赏
- 举报
syscolumns和sysobjects里已有各种表的字段、类型等值
遍历就要获取所有表属性
根据需要构建不同表，很多使用的就可使用外键关联。
表到实体时就可使用泛型
遍历就要获取所有表属性
根据需要构建不同表，很多使用的就可使用外键关联。
表到实体时就可使用泛型
freeboy827 2009-11-12
- 打赏
- 举报
表结构一样就放一起吧,加个标识字段就行了
只要数据量不大就行,可以用统一的增删改界面
只要数据量不大就行,可以用统一的增删改界面
thinkc 2009-11-12
- 打赏
- 举报
[Quote=引用 9 楼 supertyro 的回复:]
个人认为如果数据字典只做成一张表
那么扩展就不好办了，比如新需求需要新加一种类型的数据字典，而字段和以前的完全不一致，怎么办？
不是依然需要新加表么，
而且如果数据字典配合缓存使用的话，一般都比较注重效率，所有冗余这种事最好想清楚
[/Quote]
一般来说，字典表中只要用decimal和string类型就代表其他的类型（int,bool,datatime）,通过预设字段的方式，同一个字段在不同的类型中表示的含义可以不一致。当然需要另外定义表对象字段进行说明。
个人认为如果数据字典只做成一张表
那么扩展就不好办了，比如新需求需要新加一种类型的数据字典，而字段和以前的完全不一致，怎么办？
不是依然需要新加表么，
而且如果数据字典配合缓存使用的话，一般都比较注重效率，所有冗余这种事最好想清楚
[/Quote]
一般来说，字典表中只要用decimal和string类型就代表其他的类型（int,bool,datatime）,通过预设字段的方式，同一个字段在不同的类型中表示的含义可以不一致。当然需要另外定义表对象字段进行说明。
SuperTyro 2009-11-12
- 打赏
- 举报
个人认为如果数据字典只做成一张表
那么扩展就不好办了，比如新需求需要新加一种类型的数据字典，而字段和以前的完全不一致，怎么办？
不是依然需要新加表么，
而且如果数据字典配合缓存使用的话，一般都比较注重效率，所有冗余这种事最好想清楚
那么扩展就不好办了，比如新需求需要新加一种类型的数据字典，而字段和以前的完全不一致，怎么办？
不是依然需要新加表么，
而且如果数据字典配合缓存使用的话，一般都比较注重效率，所有冗余这种事最好想清楚
thinkc 2009-11-12
- 打赏
- 举报
另外多说一句，我的表结构大体如下。
Id,Type,Code,Name,OrderId,F1...F10(字符型),F11...F20(Decimal型)
Id,Type,Code,Name,OrderId,F1...F10(字符型),F11...F20(Decimal型)
thinkc 2009-11-12
- 打赏
- 举报
[Quote=引用 5 楼 l171147904 的回复:]
按照你的说法，其实所有表 结构都相同
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
[/Quote]
另外数据量庞大，这个也不可能，就整个系统的字典加起了1-2万了不起了。
按照你的说法，其实所有表 结构都相同
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
[/Quote]
另外数据量庞大，这个也不可能，就整个系统的字典加起了1-2万了不起了。
thinkc 2009-11-12
- 打赏
- 举报
[Quote=引用 5 楼 l171147904 的回复:]
按照你的说法，其实所有表 结构都相同
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
[/Quote]
呵呵，你和我同事反驳我的意见一摸一样。
从业务角度来说，表是不一样的。
字典表很仅仅是对其他某一个表的字段信息的描述，所有可以提取相同概念。
按照你的说法，其实所有表 结构都相同
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
[/Quote]
呵呵，你和我同事反驳我的意见一摸一样。
从业务角度来说，表是不一样的。
字典表很仅仅是对其他某一个表的字段信息的描述，所有可以提取相同概念。
l171147904 2009-11-12
- 打赏
- 举报
按照你的说法，其实所有表 结构都相同
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
SQL。。。都是二维的！！！
只是字段不同。。。
如果出于 易扩展和维护；考虑使用动态表！
有一个问题，你设计的1或N长表，将来数据量非常庞大（所以不建议 经常变动的表做次设计）
或你可考虑，分表保存（按模块分，或按数据类型分）
liherun 2009-11-12
- 打赏
- 举报
迷茫中
typeof 2009-11-12
- 打赏
- 举报
具体问题具体分析
thinkc 2009-11-12
- 打赏
- 举报
太笼统了吧，你的倾向是什么？
有链接地址也行。
有链接地址也行。
ztenv 2009-11-12
- 打赏
- 举报
要看具体的用法，及以后的扩展等多方面，
laomeng520 2009-11-12
- 打赏
- 举报
路过，学习
thinkc 2009-11-12
- 打赏
- 举报
我的单表字典的应用一个场景就是，将列设计转换成行设计是的外键约束问题。
列设计.EmpId,SexId,DepartId,LevelId
转换成行设计就是
EmpId,FieldType,FieldValue
这样在外键关联式只需要FiledValue字段外键关联字典的DictId就可以保证全约束。
PS:这个场景只是描述一下，可能不太恰当，但是大家应该都能看懂。
列设计.EmpId,SexId,DepartId,LevelId
转换成行设计就是
EmpId,FieldType,FieldValue
这样在外键关联式只需要FiledValue字段外键关联字典的DictId就可以保证全约束。
PS:这个场景只是描述一下，可能不太恰当，但是大家应该都能看懂。
thinkc 2009-11-12
- 打赏
- 举报
[Quote=引用 20 楼 cymandhxl 的回复:]
数据库运行的不是数据字典。首先考虑数据库。然后在表的每条记录属性上都写好注释。
然后用程序自动生成数据字典。如果数据字典确实有必要的话。
[/Quote]
建立字典表主要想利用数据库的外键约束
数据库运行的不是数据字典。首先考虑数据库。然后在表的每条记录属性上都写好注释。
然后用程序自动生成数据字典。如果数据字典确实有必要的话。
[/Quote]
建立字典表主要想利用数据库的外键约束
thinkc 2009-11-12
- 打赏
- 举报
[Quote=引用 17 楼 wanghui0380 的回复:]
我不做设计
我考虑的问题是：这个数据字典变化的有多频繁，各项间的关联度有多大。
[/Quote]
字典一旦确认，其项目（字段）基本上保持不变。
字典项之间几乎没有什么关联度，只有业务知道如何利用。
我不做设计
我考虑的问题是：这个数据字典变化的有多频繁，各项间的关联度有多大。
[/Quote]
字典一旦确认，其项目（字段）基本上保持不变。
字典项之间几乎没有什么关联度，只有业务知道如何利用。
加载更多回复（7）
