我有10个数据库表，其中6个是链接表，我应该制作一个通用的LinkTable吗？
我有 10 个数据库表 A、B、C、D、E、F、G、H、I 和 J。其中四个是必要的，但其中六个只是链接这四个表之间的链接表。我正在考虑为此构建一个通用链接表，因此
A, B, C, D, Link
执行方式与以前相同，只是链接表提供了旧六个表用来执行的所有链接。我需要链接表的三列（主题、目标、类型）。
您认为这是有道理的还是明智的做法？
如果有什么区别的话，链接表的大小不应该变大。 type 列是 TINYINT。链接主题之一是User，它几乎定义了整个链接表的大小。表中的行数将比 User 表中的行数多 5%。
I have 10 database tables A, B, C, D, E, F, G, H, I and J. Four of them are necessary, but six of them are just link tables that link between those four tables. I am considering building a generic link table for this so
A, B, C, D, Link
Performs the same way as before except that the Link table provides all linking what the old six tables used to do. I need three columns for the Link table (subject, target, type).
Do you think this makes sense or is a sensible approach?
If it makes any difference, the size of the Link table should not get big. The type column is TINYINT. One of the link subjects is User, and that pretty much defines how big the entire link table can get. There will be some what 5% more rows in the table than there are rows in the User table.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
就我个人而言，不，我不会这样做。
是的，四个基本数据表有六个链接表可能看起来“过多”。但实际上：只有一个链接表会给您带来好处，但随后您必须开始向链接添加类型（它是从表 A 到表 D 或其他内容的链接），这一切都会变得相当混乱。
对我来说，能够清楚地看到两个表之间存在链接（因为它们之间有一个链接表）比少一两个表重要得多。这确实不会产生任何重大影响 - 无论是在磁盘空间方面，还是在性能方面，这都不会带来好处……
那么再说一次：为什么要麻烦呢？有一个清晰和正确的设计，并接受这样一个事实：关系数据库需要在其主表之间有一些辅助表来使“魔法”发挥作用 - 并且不要太担心这个事实......
Personally, no I wouldn't do this.
Yes, it might look "excessive" to have six link tables for four base data tables. But really: do you gain from having just a single link table, but then you have to start adding a type to the link (it's a link from table A to table D or something else), and it all gets rather messy.
To me, the clarity of being able to see that two tables are linked, because there's a link table between them, is much more important than having one or two tables fewer. That really doesn't make a big impact in any way - neither in terms of disk space, nor in terms of performance is this going to be beneficial.....
So again: why bother? Have a clear and proper design, and just accept the fact that relational databases need a few helper tables between their main tables to make the "magic" work - and don't worry too much about that fact.....