表之间的关系
我有 3 个表：A、B 和 C。 表A与B和C具有(n:1)关系。 通常，我将 B.Id（或 C.Id）和表名称存储在 A 中。
例如，
A.ParentId = 1
A.TableName = "B"
A.ParentId = 1
A.TableName = "C"
A.ParentId = 2
A.TableName = "B"
这是一个好的解决方案吗？还有其他解决方案吗？
I have 3 tables: A, B and C.
Table A is in relation (n:1) with B and with C.
Typically I store in A the B.Id (or the C.Id) and the table name.
e.g.
A.ParentId = 1
A.TableName = "B"
A.ParentId = 1
A.TableName = "C"
A.ParentId = 2
A.TableName = "B"
Is it a good solution? Are there any other solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不是 2 个 Parentid 列？
A.ParentIdB = 1
A.ParentIdC = 3
Why not 2 parentid columns?
A.ParentIdB = 1
A.ParentIdC = 3
另一种可能性是引入另一个表 Content (D)，作为帖子和图像的“超类型”。然后，评论 (A) 中的一行将引用内容中的主键，就像帖子 (B) 和图像 (D) 中的每一行一样。帖子和图像中的任何常见字段都将移动到内容（可能是“标题”或“日期”），而这些原始表格将仅包含特定于帖子或图像的信息（可能是“正文”或“分辨率”）。这将使执行连接比在字段中包含表名更容易，但这确实意味着现实世界的实体可以既是帖子又是评论（或者实际上是帖子或评论的乘法！）。但实际上，这取决于您尝试建模的情况。
Another possibility is to introduce another table Content (D) that serves as a "supertype" to Posts and Images. Then a row in Comments (A) would reference a primary key in Content as would each row in Posts (B) and Images (D). Any common fields in Posts and Images would be moved to Content (perhaps "title" or "date") and those original tables would then only contain information specific to a post or image (perhaps "body" or "resolution"). This would make it easier to perform joins than having the table names in a field, but it does mean that a real-world entity could be both a post and a comment (or indeed, be multiply a post or comment!). Really, though, it depends on the situation that you're trying to model.