5

Im trying to use to define a one-to-many relationship in a single table. For example lets say I have a Groups table with these entries:

Group:
  Group_1:
    name: Atlantic Records
  Group_2:
    name: Capital Records
  Group_3:
    name: Gnarls Barkley
  Group_4:
    name: Death Cab For Cutie
  Group_5:
    name: Coldplay
  Group_6:
    name: Management Company

The group Coldplay could be a child of the group Capital Records and a child of the group Management Company and Gnarls Barkley could only be a child of Atlantic Records.

What is the best way to represent this relationship. I am using PHP and mySQL. Also I am using PHP-Doctrine as my ORM if that helps.

I was thinking that I would need to create a linking table called group_groups that would have 2 columns. owner_id and group_id. However i'm not sure if that is best way to do this.

Any insight would be appreciated. Let me know if I explained my problem good enough.

4

8 回答 8

7

There are a number of possible issues with this approach, but with a minimal understanding of the requirements, here goes:

There appear to be really three 'entities' here: Artist/Band, Label/Recording Co. and Management Co.

Artists/Bands can have a Label/Recording CO Artists/Bands can have a Management Co.

Label/Recording Co can have multiple Artists/Bands

Management Co can have multiple Artists/Bands

So there are one-to-many relationships between Recording Co and Artists and between Management Co and Artists.

Record each entity only once, in its own table, with a unique ID.

Put the key of the "one" in each instance of the "many" - in this case, Artist/Band would have both a Recording Co ID and a Management Co ID

Then your query will ultimately join Artist, Recording Co and Management Co.

With this structure, you don't need intersection tables, there is a clear separation of "entities" and the query is relatively simple.

于 2008-10-24T21:31:18.530 回答
3

A couple of options:

Easiest: If each group can only have one parent, then you just need a "ParentID" field in the main table.

If relationships can be more complex than that, then yes, you'd need some sort of linking table. Maybe even a "relationship type" column to define what kind of relationship between the two groups.

于 2008-10-24T21:21:55.630 回答
1

在这种特殊情况下，您最好遵循 Ken G 的建议，因为您确实在一个表中对三个单独的实体进行建模。

一般来说，这可能会出现——如果你有一个“人”表，并且正在模拟每个人的朋友是谁，举一个人为的例子。

在这种情况下，您确实会有一个“链接”或关联或婚姻表来管理这些关系。

于 2008-10-24T21:44:22.653 回答
0

这似乎是 STI（单表继承）和嵌套集/树结构的混合。嵌套集/树是一个父多个子：

http://jgeewax.wordpress.com/2006/07/18/hierarchical-data-side-note/

http://www.dbmsmag.com/9603d06.html

http://www.sitepoint.com/article/hierarchical-data-database

于 2008-10-25T15:47:36.297 回答
0

我认为最好的是使用 NestedSet http://www.doctrine-project.org/documentation/manual/1_0/en/hierarchical-data#nested-set

只需设置 actAs NestedSet

于 2008-12-12T18:16:03.537 回答
0

我同意 Ken G 和 JohnMcG 的观点，即您应该将管理和标签分开。然而，他们可能忘记了一个乐队可以在一段时间内拥有多个经理和/或多个经理。在这种情况下，您将需要多对多关系。

  • 管理层有很多乐队
  • 乐队有很多管理层
  • 标签有很多条带
  • 乐队有很多标签

在这种情况下，您最初使用关系表的想法是正确的。那就是在家完成多对多的关系。但是，group_groups 可以更好地命名。

最终这将取决于您的要求。例如，如果您要存储 CD 标题，那么您可能更愿意将标签附加到特定 CD 而不是乐队。

于 2008-10-24T22:15:54.943 回答
-1

Yes, you would need a bridge that contained the fields you described. However, I would think your table should be split if it is following the same type of entities as you describe.

于 2008-10-24T21:22:55.067 回答
-1

(I am assuming there is an id column which can be used for references).

You can add a column called parent_id (allow nulls) and store the id of the parent group in it. Then you can join using sql like: "Select a., b. from group parent join group child on parent.id = child.parent_id".

I do recommend using a separate table for this link because: 1. You cannot support multiple parents with a field. You have to use a separate table. 2. Import/Export/Delete is way more difficult with a field in the table because you may run into key conflicts. For example, if you try to import data, you need to make sure that you first import the parents and then children. With a separate table, you can import all groups and then all relationships without worrying about the actual order of the data.

于 2008-10-24T21:30:27.250 回答