从类到数据库结构的三种方式

假设用户类有编号、姓名和性别三个属性：

 

用户类

编号 姓名 性别

 

以用户（User）类与为例，讨论从类到数据库结构的三种方式：

1. 一张表对应一个类

表结构：

User

User_ID

User_Name

Gender

表数据：

User 表

User_ID	User_Name	Gender
001	张强	男
002	李丽	女

 

这样的表结构最简单，但也是最不灵活的。比如，如果想将所有用户的性别“男”改成性别“男性”，则需求修改所有性别为“男”的用户的数据。

而且，这样的结构可能造成空间浪费。因为，这样存储的性别，大部分都是重复的，没有做到数据重用。仅本例的性别字段来说，还算勉强过得去，如果是“部门”等长数据字段，就能明显感到空间的浪费了。

 

2. 两张表对应一个类

表结构：

User

User_ID

User_Name

Gender_ID

 

Gender

Gender_ID

Gender_Name

表数据：

User 表

User_ID	User_Name	Gender_ID
001	张强	1
002	李丽	2

Gender 表

Gender_ID	Gender_Name
1	男
2	女

 

这样的数据库结构比较常见，灵活性较好，空间利用率高。要将性别“男”修改成性别“男性”，只需要修改 Gender 表的一条记录就好了。但是，它的灵活性，还是不如下面的第三种方式。

3. 三张表对应一个类

表结构：

User

User_ID

User_Name

 

Gender

Gender_ID

Gender_Name

 

User_Gender

User_ID

Gender_ID

表数据：

User 表

User_ID	User_Name
001	张强
002	李丽

Gender 表

Gender_ID	Gender_Name
1	男
2	女

User_Gender 表

User_ID	Gender_ID
001	1
002	2

 

这样的数据库结构，在空间上比第二种稍微浪费了一点，但是，它的灵活性是最好的。

用这种结构，可以在不对原 User 表进行任何修改的情况下，为它添加一个新的“性别”字段。当然也可以添加更多其它字段。

Gender 表与 User 表是通过 User_Gender 间接发生关联的，添加或删除 Gender 和 User_Gender 表对 User 表没有任何影响。这样的数据库结构的耦合性最小，所以结构最灵活。

对于“性别”这个字段，一般并不需要这样高的灵活性，直接采用第二种方式就好了。在这里拿它来做例子，只是为了便于阐述。

 

 

原文地址：http://blog.tanggaowei.com/2008/11/post-48.html