不同的用户类型/对象在同一个表中拥有自己的内容 - 如何?
知道如何将不同的对象联系在一起吗?我想要实现的用例是评论通常由用户拥有。所以我有一个 user_id 。但我也有公司页面,公司拥有其页面上的内容,因此所有者是 company_id。 (其中 ofcoure 由多个用户管理)
一种方法是有 2 个表 user_comments 和 company_comments 但问题是我每个对象需要 2 个表,如果我添加更多用户类型,那么我需要多个表。我想要实现的是 1 个表,其中包含:
comment_id PK
owner_id (user id or company id or etc...) - fk?
假设我创建一个所有者表只是为了将所有用户类型链接在一起,那么列是什么来将这些全部放入或者是否有其他方式?
Any idea how I can relate different objects together? Usecase i am trying to achieve is Comments are usually owned by a user. So i have a user_id for it. But I have company pages also where the company owns the content on its page so the owner is the company_id. (Which ofcoure is admin by several users)
One way is to have 2 tables user_comments and company_comments but the problem is then i need 2 tables per object and if i add more user types then i need to multiple the tables. What i want to achieve is 1 table which has:
comment_id PK
owner_id (user id or company id or etc...) - fk?
So let's say i create a owner table just to link all user types together, what would the columns be to get these all in or is there some other way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
人和组织是超类型/子类型关系中事物的一个很好的例子。它们并不相同,但也不是完全不同。他们有许多共同的属性。个人和组织都有地址和电话号码,个人和组织都可以成为诉讼中的原告和被告,并且个人和组织显然都可以在系统中拥有评论。
要在 SQL dbms 中实现这一点,请将人员和组织共有的列放在一个名为“Parties”的表中。人员特有的列位于人员表中;组织特有的列位于组织表中。使用视图(每个子类型一个)来隐藏实现细节;您的客户使用视图,而不是表格。
您可以使用超类型表“Parties”中的键作为评论的所有者。 (我认为。)
这是一个简化的例子。
使用 dbms 提供的任何功能使视图可更新。 (可能会触发。)然后应用程序代码可以插入到适当的视图中。
People and organizations are a good example of things in a supertype/subtype relationship. They are not identical, but they are not utterly distinct. They share many attributes. Both people and organizations have addresses and telephone numbers, both people and organizations can be plaintiffs and defendants in a lawsuit, and both people and organizations can apparently own comments in your system.
To implement this in a SQL dbms, put the columns common to both people and organizations in one table called, say, "Parties". Columns unique to people go in a table of people; columns unique to organizations go in a table of organizations. Use views, one per subtype, to hide the implementation details; your clients use the views, not the tables.
You'd use the key from the supertype table, "Parties", as the owner of your comments. (I think.)
Here's a simplified example.
Make the view updatable using whatever feature your dbms provides to do that. (Probably triggers.) Then application code can just insert into the appropriate view.