像这样的关系，大家数据库是如何设计的？
0
悬赏园豆：80
[已解决问题]
解决于 2014-11-10 08:53
比如说一个用户表：
主键
用户名
密码
地址（包含省市区）
用户类别（公共字典表）
省市区：
主键
区域编码（320000）
显示值（江苏省）
公共字典表：
主键
显示值（类别A）
实际值(101)
分组名（比如用户类别）
省市区数据和公告字典表数据是分开存储的，然后界面展示数据(江苏省和类别A)，讲选择的数据保存到数据库。
这个保存的数据，大家保存的是实际的值（320000和101），还是显示的值（江苏省和类别A）？
保存显示的值，查用户就可以单表就能查询出来。但是维护怎么维护？
保存实际值，可能查一个用户就要关联三个表去查询，才能查询出来。
像这种情况，大家如何进行取舍？
最佳答案
0
如果按照范式的话，其实就是用户表要有三级地区ID的外键和类别ID的外键，但这样查询要关联4个表，性能会降低，但从另外角度考虑，比如删除类别时，如果有外键约束的话会不允许删除，这样就保证了数据的一致性和完整性，所以综合考虑看你取舍.
收获园豆：20
其他回答(5)
0
有时候这样，有时候那样，看心情
收获园豆：15
多么痛的领悟。。。
@xiaocong_soft: 基本上在不过千万级别的系统中，咋整都没事。过了千万，就要各种考虑，一下子也说不清。
@爱编程的大叔: 嗯。比较纠结这个事情。查个简单的用户表，就要关联三个表，如果用户再有个角色权限什么乱七八糟的东西。。。写完也是醉了。。。
@xiaocong_soft: 绝对不重复，而且不可能修改名称的，可以直接保存文本。比如省份。
至于要是哪天天朝突然大改省份名称，那个孔子说过，我死后，哪管洪水涛天。
你就是think too much.
@爱编程的大叔: 哈哈。随他去吧。
0
可以冗余地保存两个数据。多数时候是可以接受的，甚至于挺合理的。
比如 当时张三做了某某事，后来改名为李四，可是那个时候他的名字就叫张三，档案调出来的还是张三而不李四。
收获园豆：15
嗯。像这种操作记录类似的是合理的。如果说用户类别需要维护的，张三保存的是用户类别A，有一天统一改名叫用户类别B，查询的时候按照用户类别B查的话，可能就找不到张三这个人了。
像这种问题真是蛋疼了。。。还是不能想太多，想太多就容易纠结。。。
0
额，保存实际值吧，类别的修改记录写log啊.......
收获园豆：5
0
该吃吃，该喝喝
收获园豆：5
0
看需求，完全没有性能压力，就按范式来，有就看有到什么程度再决定了
收获园豆：20
嗯。像省市区这种地址，你是分三个字段保存的，还是一个字段？
查询的时候，这种关系，是关联省市区表三次吗？
看来省市区这是个蛋疼的问题，我觉得还是直接保存江苏省xx市xx区好了。
@xiaocong_soft: 你是说这个啊，这个就是普通的多级字典项，字典项的CODE是按级增加的比如省是三位001下面的城市就是001001，依次排下去，一次查询就够了
