简体繁体 English

多对多（实际上太多）关系的数据库设计

[英]Database design for many(few) to many(actually too many) relationship

原文 2016-05-31 08:46:57 5 1 mysql/ sql/ database/ database-design

I have two tables, user and programs. 我有两个表，用户和程序。 Now I have only, say, 5-10, programs and tens of thousands of users, who can be enrolled in any of the programs (can be enrolled in multiple programs too). 现在，我只有5-10个程序，成千上万的用户可以注册任何程序（也可以注册多个程序）。 So in a case of many to many relationship, I was thinking of creating a separate table, say link_user_program, to store which programs a user is enrolled in. 因此，在存在多对多关系的情况下，我正在考虑创建一个单独的表，例如link_user_program，以存储用户注册了哪些程序。

But if I have tens of thousands of user and just 10 programs, won't this consume extra space and increase query time than just storing the programs enrolled in the user table (maybe comma separated program ids or a boolean column for each program)? 但是，如果我有成千上万的用户并且只有10个程序，这会不会比仅存储在用户表中存储的程序（可能是逗号分隔的程序ID或每个程序的布尔列） 消耗更多的空间并增加查询时间 ？

What are the pros and cons of the above two designs or is there a better alternative? 以上两种设计的优缺点是什么，还是有更好的选择？ What if there's a situation that new programs may be added in the future (but still way considerably less than the number of users)? 如果将来可能会添加新程序（但仍然远远少于用户数量）怎么办？

1 个解决方案

From OO domain design perspective, recommend to use a many to many link table; 从OO域设计的角度来看，建议使用多对多链接表； forget about extra space, for query time, you can setup index to improve performance. 不用担心多余的空间，在查询时间上，您可以设置索引以提高性能。

without link table, if will make you difficult to add/delete a problem in future. 没有链接表，如果将来会使您难以添加/删除问题。