mysql问题分析各个表之间的关系（主外键引用关系），创建四个表

你这个就是把 Car表的type_id 和Types表的 types_id 进行关联就可以 那你tpyes表中的type_id 就要是primarykey 给你说个和你这个一样简单的例子吧 表a id-客户序号 primary-key name-客户名称 表b id-序号 nid-客户序号 products-产品 下面有增删改查 insert into 表b (`nid`,`products`) values ('1','手机')update 表b set `products` = '电话' where `nid` = '1' and `products` = 手机'delete * from 表b where `nid` = '1' and `products` = 手机' 如果你要查询的话用下面这句: select b.products, a.name from 表b as b, 表a as a where 表b.uid = 表a.id

方法和 *** 作步骤如下：

1、首先，创建一个测试表，如下图所示，然后进入下一步。

2、其次，插入测试数据，如下图所示，然后进入下一步。

3、接着，完成上述步骤后，查询表中的数据，“select t.* from test_tbl2 t ”，如下图所示，然后进入下一步。

4、最后，完成上述步骤后，编写sql，两个表通过pid与id关联， “select t1.*, t2.* from test_tbl1 t1 join test_tbl2 t2 on t1.p_id = t2.id”，如下图所示。这样，问题就解决了。

这个问题问的好，要弄一个表很容易，关键是表设计出来是否合理！

如果表设计的好，则会相当清晰，易于理解，后续开发上事半功倍，维护也方便；如果设计的不好，则难以理解，维护困难，代价大。

表与表之间的关系有三种：1.一对一，2.一对多，3.多对多

一对一的表，两表的属性实际上完全可以合并成一个表，共用一个主键即可；

一对多的表，可以设中间关联表，也可以将关联表并入“多”这头；若设独立关联表，则可引入“多”这头的主键作为其主键，也可另立主键，并将“一”和“多”两表的主键作为关联表的外键；

多对多的表，则必须设中间关联表，关联表设独立主键，并引入两个“多”头的表的主键作为关联表的外键。

这是上述三种关系表在键处理上的基本原则。

范式还是要遵循的，这套理论还是科学合理的。不要相信反范式设计，反范式设计在规模庞大时，数据冗余多，编码及维护会变得困难，万一考虑漏掉的将导致数据不一致，甚至酿成灾难。严格按照范式理论来设计数据库，将使你编码及维护时少 *** 很多心。

一般来说，先进行需求分析，然后画出数据流图，然后再根据数据流图画出ER图，然后再根据ER图创建各种表。表是根据ER图来创建的，表设计的合不合理，关键是ER图抽像的合不合理。在抽像ER图时，一般遵循这样的原则：

能用1对1的，就不用1对多；能用1对多的，就不用多对多，往简单化方向靠；

能当属性处理的，尽量当属性，而不是当实体处理去另立新表，这样可使问题简化。

把意义相近联系紧密的属性放在一张表内，而不是拆在多张表中。

看了一下你上述几张表，我认为不合理，户主是人，家庭成员也是人，把他们分在户主表和家庭成员表中不合理，他们是同一类的，宜合在一张家庭成员表中，并增加一个标志性字段，以指明哪个人是户主。另外，宜建立一张地址表，以取代户主表，地址表中宜指明乡场镇、村巷道、几区、门牌号等与地址关系紧密的属性，把户籍、联系方式、户主等字段拿走，他们不是地址属性，这几个宜放在成员关系表中，户籍是人的属性，并非地址的属性，联系方式就更明显了，要联系的是人，而不是地址。

很明显，地址和家庭成员是一对多关系，一个地址同时可以住着多个成员，而一个成员同时只能住一个地址，这样，设计成地址表和家庭成员表之后，要在家庭成员表中再加一个地址外键字段，把地址表的主键当作家庭成员表的外键填入，这样，成员表中的每个人都可以通过地址外键字段到地址表中找到其所住地址。另外，成员表中也指明了哪个人是户主，也指明了每个人的户籍和联系方式，这些信息你都可以找得到。

---