［百分救助］请教一个数据库设计的问题！到底哪种方法好？

[isfei]

正在设计一个数据库，主要是进行“省份、城市、区县”的设计。主要用途是由省份推出城市，再由城市推出区县。
　　省份编号、城市编号和区县编号是内部自定义的。
　　例如：江苏省　32　　南京市　01　　新街口　01
　　　　　江苏省　32　　南京市　01　　鼓楼　　02
　　　　　江苏省　32　　南京市　01　　白下　　03

　　现在已经想到两种方法，但不知道这两种方面是否好。或是有更好的办法解决！
　　请高手指教！

方法一：
　　设计一张表，内含７个字段。分别为：auto（自动编号）、prov_id（省份编号）、prov（省份名称）、city_id（城市编号）、city（城市名称）、coun_id（区县编号）、coun（区县名称）。


方法二：
　　设计三张表。
　　第一张prov表，内含auto、prov_id、prov；
　　第二张city表，内含auto、prov_id、city_id、city
　　第三张coun表，内含auto、prov_id、city_id、coun_id、coun
　　用这三张表建立联系。
　　第一张表的 prov_id 对应第二张表中的 prov_id
　　第二张表的 prov_id city_id 对应第三张表中的 prov_id、city_id

[isfei]

还有一种办法就是：
Table 1. prov_id prov
Table 2. prov_id city_id city
Table 3. city_id coun_id coun

例如：
江苏　32　　　南京　3211　　　新街口　321101
江苏　32　　　南京　3211　　　鼓楼区　321102

不知道这样设计如何？

[isfei]

　　auto表示机器自动生成的号码，而 prov_id、city_id、coun_id 是手动生成的编号。
To: ZhangYv
　　你的办法是好，但是：
　　江苏省　32　　　　南京　01
　　安徽省　33　　　　合肥　01
　　浙江省　34　　　　杭州　01

　　这样不就成了有重复的编号了吗？

[isfei]

另外，这样的 3NF 会不会影响速度、安全　等方面　的问题呢？

[寻开心]

同意zhangyv，楼主是什么意思，难道你要得结果是：
江苏省　32　　　　南京　01
　　安徽省　33　　　　合肥　02
　　浙江省　34　　　　杭州　03
城市号也不可以重复吗，那么下面的区县号是否也这样呢？

[ZhangYv]

当然是第二种啊，3NF的。用第一种你将会出现无数错误！

[ZhangYv]

方法二：
　　设计三张表。
　　第一张prov表，内含auto、prov_id、prov；
　　第二张city表，内含auto、prov_id、city_id、city
　　第三张coun表，内含auto、city_id、coun_id、coun
　　用这三张表建立联系。
　　第一张表的 prov_id 对应第二张表中的 prov_id
　　第二张表的 prov_id city_id 对应第三张表中的 city_id

auto是干什么用的？

[ZhangYv]

第一张prov表，内含auto、prov_id、prov；
　　第二张city表，内含auto、prov_id、city_id、city
　　第三张coun表，内含auto、city_id、coun_id、coun
　　用这三张表建立联系。
　　第一张表的 prov_id 对应第二张表中的 prov_id
　　第二张表的 city_id 对应第三张表中的 city_id
符合3NF的，这样可以了。

[ZhangYv]

to isfei(高飞)
你的"还有一种方法"是不可取的.

[bm1408]

在达到3NF！
要消除部分函数依赖和传递依赖！

[isfei]

up

[寻开心]

你在定义city_id的时候自动加上prov_id在高位？
这样是可以建立唯一的关联
但是操作起来不容易了
一旦发生城市划分转移的情形，更改起来还是面临多个表的问题。
例如 南京的编号不是3211了，换成3311
那么你的第三个表是不是也要全部更新一遍。

前面几个帖子里面，我一直不希望这种现象发生，想上层更改的时候下层可以自动响应，所以让你一直用auto字段做关联
表的结构就是
Table1 auto prov_id prov
Table2 auto Key_auto city_id city
Table3 auto KeyAuto2 count_id count
key_auto 关联到Table1里面的auto
key_auto2 关联到Table2里面的auto
这样做除非把表的内容从一个数据库向另外一个数据库复制，否则在一个数据库内部使用auto字段做关联不会有问题。

[sharesunning]

第三个表设计有问题，在PROV_ID和CITY_ID存在着依赖关系，楼主不知道时候在设计表的时候搀杂了程序设计如何实现的因素，从单纯的实体关系中看，省份和城市之间是一对多的关系，其中前者具有支配作用，一样的城市和区县也是一对多的关系，前者有有支配作用，后者依赖前者，而楼主在设计第三个表中，可能是想到可以直接从第三个表中找到省份，而且每个表中不知道如何定义主键，象在第一个表中，是用AUTO还是用PROV_ID,楼主好像是想用PROV_id,如果那样的话，那么就没有必要用AUTO产生唯一的表示，所以建议采用如下的设计
省份：prov_id(auto,p) prov（省份具有的属性）
城市：city_id(auto,p) prov_id city(城市具有的属性)
区县：coun_id(auto,p) prov_id coun(区县具有的属性) 编码
在区县上设计一个编码字段，可以在查询的时候依据编码进行处理，而生成编码的过程就由程序控制了

[isfei]

To: happy__888([顾问团]寻开心)
　　其实我一直不想用 AUTO 自动生成的内容做关联，我个人总认为有一定程度的危险性。

To: sharesunning(快乐山猪)
　　你说的很对，我的确是想找一个好的关联字段。但两个一对多，使我感到头痛。

　　所以基于以上的想法，使我想到了另一个新的做法，不知道是否可以，请各位指教！
　　PROV_ID CITY_ID COUN_ID NAME
　　32 00 00 江苏省
　　32 01 00 南京市
　　32 01 01 新街口
　　32 01 02 鼓楼区
　　32 01 03 白下区

　　所有的省份，CITY_ID 和 COUN_ID 字段都为00。
　　所有的城市，COUN_ID 字段都为00。
　　这样就不会有重复的字段了。

[ZhangYv]

你可以参考一下邮政编码,或许会有启发.

[asiaec]

哦？

你为什么不找本数据库概论的书看看 两种方法没有可比性啊

另外我同意楼上的意见 没必要用auto做主马 容易引起混乱

[isfei]

我不想使用邮政编码来做这样的东西，只想按照身份证的前6位来做这样的东东。

[libi]

E-R图如下：
属于 属于
县----------市----------省
* 1 * 1

本来应该用5张表（县、市、省，以及两个关系），但是这里正好是1..*关系，可以被“吸收”，所以用3张表就可以了。
Table 1. prov_id prov
Table 2. city_id city 所属prov_id
Table 3. coun_id coun 所属city_id
这也就是你所说的"还有一种方法"。但是这里的prov_id是内部流水号，不是身份证上的编码，那个编码是prov的一个属性字段。其它相同。

至于你后来提到的“另一个新的做法”，那实际上是把地区作为一个省、市、县的三元关联类，这与实际情况不符，但它效率高。这就是软件开发中的问题，我们应该怎样去设计，为了解决问题，我们设计出来的程序不一定与真实情况符合，能解决问题就行。但是OO的设计思想就是要尽量贴近真实情况，这样，当系统发生变动时，软件跟着变动就容易。例如happy__888([顾问团]寻开心)所说的城市划分转移时，“另一个新的做法”处理起来就不方便了。
如何取舍就是你自己的问题了。

[python与大数据分析]

可以设计成一张表
000 000 000 000
省 市 县 区
树形码 身份证地区码 省 市 县 区
先有省再有市 先有市再有县 依次递推下去

[寻开心]

C语言有灵活的指针操作，它的危险性也很大，一旦出现错误，很可能导致程序崩溃，但是我们要因此而放弃它吗？！
数据库的AUTO字段也是这样啊，如果你知道可能出现问题的地方，在程序当中加以特殊处理就可以了。

要更安全，你是可以不使用auto字段，而是自己建立一个ID，但是这样做的问题是你要自己写程序来判断生成的ID是否是唯一的，其实效果都是一样的。
对于这个问题，你还可以仿照AUTO的生成机制，系统自己定义一个当前最大AUTO数值，每次新建AUTO数字的时候，都使用这个最大AUTO数值作为新生成的数字，然后把最大值加1，以后遇到删除或者修改操作的时候，最大AUTO数值必须要保持不变，这样就可以保证生成唯一的数字了。麻烦在于这个最大数值你放在那里，数据库可以有自己的位置保留这个数值，我们自己就不好办，总不能再开一个表或者字段，单独放它吧。

[wshWaWa]

libi的方案其实已经符合BCNF了:)