问题描述
最近看到一个朋友说自己公司使用的表结构为多对多的关系，现在他们的customer已经860万了，而中间表m_customer_category 也有900多万了，如果按类型查找客户资料的话巨慢，就是customer，m_customer_category,custoemr_category三张表多对多关系，现在使用客户类型快速查找非常慢。然后自己也想了想这种设计，感觉查询确实非常郁闷，而且想不出它到底有什么优势。希望大家一起来讨论讨论。 问题补充：quickphp 写道
解决方案
首先Customer与Order不是一对多的关系吗?一个客户可以有多个订单,一个订单只能属于一个客户,如果像我说的,首先表的设计就有问题不过如果你真要这么设计的话...首先考虑客户类型和订单状态字段是否有做索引的需要,select t3.* from( select * from Customer where customer_type=80 ) t1 inner join Customer_Order t2 on t1.customer_id=t2.customer_idinner join ( select * from Order where order_state='已经到帐') t3 on t2.order_id=t3.order_id
解决方案二：
1.首先要确定的customer与custoemr_category是不是多对多的关系,如果是的话,建议这么做,因为这么做可以尽量的满足范式,至于范式的作用你可以自己去查,当然范式也不是死的,有的时候为了业务的需要也会做一些反范式的设计的,但是一般来说还是尽量按范式来设计.2.还有就是对于大数据量的优化问题了,索引,分区,数据水平切分等技术,3.还有就是维护的问题,如果你觉得麻烦可以考虑用级联操作
解决方案三：
中间表就是用来存放关联关系的，尤其是多对多得时候，如果你只用Customer和Order两张表来存多对多，肯定是可以得，但是，在Customer表里就会有那么几条记录，绝大部分内容都一样，唯独OrderID不一样。这个好像挺浪费空间的。
解决方案四：
以前公司都不用哪种关联，现在公司都用。我也给问了他们为什么要用，大家说不出所以然来，反正一直都在用，等待答案。
解决方案五：
Customer,Order关联 只需要1对多就可以了，多对多的情况是有的，不过感觉不适用你的需求。
解决方案六：
个人感觉，Customer_Order这个没啥用，直接用Customer,Order关联不就可以了吗
解决方案七：
无论多对多还是什么多，都必须在两个主表里存储冗余数据，中间表崩溃的可能性非常大，如果中间表损坏，那么你的数据是不是都成了孤岛，尽管中间表使用联合主键来查询速度也不会说很慢，但是如果主表里有冗余数据岂不是根本不用连表，中间表的作用不过就是存储原始数据而已，可作为冗余更新的凭证