我需要为基于教育的应用程序创建一个数据模型。我想问的问题是，为具有多对多关系的两个表创建一个联结表，还是为处理所有多对多关系而创建一个大联结表，是更好的选择？
说，我有学生，导师，学科，年级表。
student and tutor are in many-to-many
tutor and subject are in many-to-many
tutor and grade are also in many-to-many
A student can have many tutors for one subject of one grade.
There can be many tutors for one subject of one grade.
A subject of one grade can be taught by many tutors.
以上只是这些关系的几个示例。
我的问题是如何有效地建立这些关系的模型？对于每种关系，我应该有一个联结表，还是应该将它们合并为一个大的桥接表？
因此，如果我也有一个类表，then from the big bridge table I can get for which class which tutor taught which subject of what grade along with other details of the class.
答案 0 :(得分：1)
让我们假设数据库还不是电子的，而是一个好的旧文件柜。 假设该数据库用于图书馆，并且要维护两种不同的“多对多信息”：书籍的作者（合着的书籍中有> 1位作者），书籍的读者，读者对读者，可能在图书馆的多个站点中预订书籍，...
您是否会想到将所有这些截然不同的信息存储在一个大文件柜中？想象一下对用户有何后果？有时，仅仅因为其他人就在那里做“读者阅读器”而被禁止做“读者阅读器”。如果并且当您设法获得访问权时，又该轮到您这样做了，例如说“书籍作者”，您的工作将会变慢，因为所有“书籍读者”的内容都可能介于两者之间，您必须花钱多余的时间只会跳过不需要的东西。例如，如果必须执行“转换操作”，则会发现一种新型的多对多事物，并且必须将其集成到单个文件柜中，即 整个 执行转换操作时，数据库无法访问（人们添加尚未使用的颜色的备案卡）。等等。这些不良特性几乎相当于电子等效物的1-1。
正如其他人所说：不要害怕桌子。这就是DBMS擅长的。
编辑
简述：只需将每种事实类型的表保存在一张表中，就可以避免（/试图发现）怪异的抽象，例如“它们都是属性” /“它们都是多对多-关系” / ... 。他们很讨厌，因为最终用户/业务用户不会“看到”它。因此，制造它们没有商业价值。