请问数据库在创建表的时候如何设计表关系，一对一，一对多，多对多 请高手举例说明。谢谢！！！

多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。

按照数据库的增删查改 *** 作，多对多关系的查找都可以用inner join或者

select * from 主表 where id in (select 主表id from 关系表)

1，角色任命型

特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。

界面特点：显示主表，用checkbox或多选select设置多选关系。

例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。

增加关系：如果没有组合纪录，insert之。

删除关系：如果有组合纪录，删除之。

2，集合分组型

特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。

界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表）

增加关系：同版主任命型。

删除关系：同版主任命型。

3，明细帐型

特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。

界面特点：显示关系表，用radio或下拉设置单选关系。

例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。

增加关系：不管有没有组合纪录，insert之，纪录时间。

删除关系：根据关系表PK删除。

4，评论回复型

特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。

界面特点：回复文本框。

例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

5，站内短信型

特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。

界面特点：回复文本框。

例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

6，用户好友型

特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。

界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。用户的好友，也是用户（用户表-好友关系表-用户表）

增加关系：同版主任命型。

删除关系：同版主任命型

目前数据库中大约有

100

张表，

1)

其中一张是用来保存产品类型的

table1

。例如ID

|

typeint

|

varchar(500)

2)

每个类型的产品会有不同的相关信息，table3

这些信息对应了其余的多张表，但是每个表的结构相似，最多4

个字段，例如

ID

|

data1

|

data2

|

table2_FK

3)

另外一张表是用来保存所有类型的具体产品的名字的，

table2

ID

|

name

|

table1_FK

int

|

varchar(500)

|

引用这应该把table2

table3

这种表合并为一张表

就这么用两张表差不多吧，

保存产品类型的

table1

1对多个产品

ID

data1

data2

data3

data4

type

table1_FK

data1,data2

属于一张表

data3,data4

属于一张表

显然这样做效果不是很理想啊，因为表很多，这样定义的话在新表中大概就会有很多字段啊

引用这个问题一定会存在的，如果你要减少表的数量，一定不可避免地要多出一些冗余字段，

没有哪个系统的数据库表设计得有很完美的，

有些东西没法都是最好的，比如，你要查询的性能，就得减少表的联查询，

要减少表自然就要看需求满足再合并一些表，自然就有了冗余字段，

只是想办法找到一个性能和冗余字段的平衡点，也就是最佳结合，这是要不断去试的

---