通过 magic-table 建立关系
我遇到了一个有趣的 SQL 表（列出了列名）：
From_TableName |发件人 ID | To_TableName | To_Id
据我了解，该表用于数据库中的所有表关系。数据库中的数据并不多（前面提到的表中超过 10000 行），因此，我想，性能并不是那么重要。我不是 SQL 专家，所以我决定在这里问：我应该将其发送给 DailyWTF 还是在某些情况下这是一个可行的解决方案？
我的想法：我只是看不出这种方法有任何好处。当然，您只需要一张桌子来处理您的所有关系，但这并不是一个优点。我不确定当您创建新表时是否真的减少了工作。除非您想让用户做任何事情，否则必须在某处存在某种验证逻辑（什么样的关系是有效的），并且您需要更新它。
I encountered an interesting SQL table (column names listed):
From_TableName | From_Id | To_TableName | To_Id
From what I understood, this table is used for all table relationships in the database. There's not a lot of data (more than 10000 lines in the previously mentioned table) in the database, so, I guess, performance was not that important. I'm not a SQL expert, so I decided to ask here: should I send this to DailyWTF or is this a viable solution in some situations?
My thoughts: I just don't see any upsides with this approach. Sure, you only need one table for all your relationships, but that's hardly a plus. And I'm not sure if there's really less work, when you create a new table. Unless you want to let your users do anything at all, there must be some kind of validation logic (what kind of relationships are valid) somewhere and you need to update that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这很可能用于在应用程序层中映射类似实体的对象（希望），而不是在 sql 数据库本身中。
即使不推荐，我以前也见过这些方法。
这可能会导致一些严重的性能问题，但正如您所说，数据库非常小。
但我不认为这完全值得 DailyWTF 。
This was most probably used in mapping Entity-like objects in the application layer (hopefully) and not in the sql database itself.
And even though it is not recomended, I have seen these approaches before.
This can lead to some serious performance issues, but as you said, the database was quite small.
I do not think that this fully warants a DailyWTF though.
我曾经开发过这样的系统，用户可以随时添加新表和关系，而无需开发人员参与。
I worked on a system like this once where the users could add new tables and relationships at any time, without developer involvement.
我在自定义 ORM 中见过类似的设计。
如果满足以下条件，则这是有意义的：
I've seen a design like that in a custom
ORM.This makes sense if:
使用单独的表来包含关系信息的方法并不罕见。许多框架（例如 Rails）使用它们来存储多对多关系。然而，在这些情况下，通常每个关系都有一个表，表中只有两者的 ID。
话虽如此，我以前从未见过这种方法，这种方法不是为每个关系使用单独的表，而是将所有关系收集在一个表中。与我刚才描述的方法相比，这种方法唯一真正的缺点是性能。好处是（无论如何，对于某些人来说）通过减少表来减少数据库中的混乱。
但不，绝对不值得 DailyWTF。我会质疑这个设计，但不会嘲笑它。
The approach of using separate tables to contain relational information is not all that uncommon. Many frameworks (Rails, for example) use them to store many-to-many relationships. In these cases, however, it's normally one table per relationship, with only the IDs of both in the table.
Having said that, I haven't seen this approach before, where instead of having separate tables for each relationship, all relationships are collected in one. The only real downside to this approach compared to the approach I just described would be performance. The upside would be (for some, anyway) less clutter in the database by having less tables.
But no, definitely not DailyWTF-worthy. I'd question the design but not ridicule it.