一对多对自身
如何为一个与其自身具有一对多关系的实体构建一个表? 具体来说,我正在开发一款跟踪动物繁殖的应用程序。 每只动物都有一个ID; 它还有一个父亲 ID 和一个母亲 ID。 因此,从父亲或母亲到其后代,可能存在一对多。 我倾向于这样的事情:
ID INT NOT NULL PRIMARY KEY
SIRE_ID INT
DAME_ID INT
为购买并添加到种畜中的那些动物记录空值,并在表中记录其余动物的 ID。
所以:
- 有人可以指点我吗 讨论的文章/网页 建模这种关系?
- ID 应该是 INT 还是某种类型 字符串? INT 中的 NULL 会 表明该动物没有 数据库中的父母,但是一个字符串 具有特殊标志值的可以是 用来表示同一件事。
这可能是最好的模型吗 通过两个表? 我是说一张桌子 为动物和一个单独的 仅表明亲属关系的表格,例如:
动物
ID INT 非空主键
亲属关系
ID INT 不为空主键外键
SIRE_ID INT 主键外键
DAME_ID INT PRIMARY KEY FOREIGN KEY
我对上述情况表示歉意:我的 SQL 生锈了。 我希望它能传达我的想法。
How would one structure a table for an entity that can have a one to many relationship to itself? Specifically, I'm working on an app to track animal breeding. Each animal has an ID; it's also got a sire ID and a dame ID. So it's possible to have a one to many from the sire or dame to its offspring. I would be inclined to something like this:
ID INT NOT NULL PRIMARY KEY
SIRE_ID INT
DAME_ID INT
and record a null value for those animals which were purchased and added to the breeding stock and an ID in the table for the rest.
So:
- Can someone point me to an
article/web page that discusses
modeling this sort of relationship? - Should the ID be an INT or some sort
of String? A NULL in the INT would
indicate that the animal has no
parents in the database but a String
with special flag values could be
used to indicate the same thing. Would this possibly be best modeled
via two tables? I mean one table
for the animals and a separate
table solely indicating kinship e. g.:Animal
ID INT NOT NULL PRIMARY KEY
Kinship
ID INT NOT NULL PRIMARY KEY FOREIGN KEY
SIRE_ID INT PRIMARY KEY FOREIGN KEY
DAME_ID INT PRIMARY KEY FOREIGN KEY
I apologize for the above: my SQL is rusty. I hope it sort of conveys what I'm thinking about.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(9)
看起来你想建造一棵树之类的东西。
怎么样?:
有一些功能可以在与其自身有关系的表中进行查询。 请参阅连接方式的语法:http:// www.adp-gmbh.ch/ora/sql/connect_by.html
Seems like you want to build something like a tree.
What about something like?:
There are some functionality for doing querys in tables with relations to themselves. See the syntax of Connect By: http://www.adp-gmbh.ch/ora/sql/connect_by.html
我认为,既然很明显动物只有一个父亲和一个母亲,那么使用一张桌子是最有意义的。 我的偏好是使用 int 或 bigint 作为行标识符,空值表示没有关系。 那么,我可能会使用其他一些方法来唯一标识动物,这样它们就不会在表中出现两次,并在该列上创建唯一索引。
I think that since it is clear that an animal only has one sire and one dam, that using a single table would make the most sense. My preference is to use int or bigint as the row identifier, with a null value signifying no relationship. I would probably, then, to use some other method to uniquely identify animals so they don't end up in the table twice and create a unique index on that column as well.
使用 SQL 的“connect by”子句来告诉它遵循哪个层次结构。
Use the "connect by" clause with SQL to tell it which hierarchy to follow.
这并不是真正的一对多关系,除非动物可以有很多父母。
我会将其保留为一张表,其中包含动物的唯一密钥 ID、每个父母的一个 int 字段,以及可能用于用于有关动物的一般注释的文本字段,例如在这种情况下购买它的地方。
It's not really a one to many relationship, unless an animal can have many parents.
I would leave it as a single table with the unique key ID for the animal, one int field for each of the parents, and probably a text field to use for general notes about the animal, like where it was purchased if that's the case.
INT 是 ID 列的更好选择,并且更适合您使用序列来生成唯一 ID 的情况。
我认为将设计分成两个表没有任何好处。
INT is the better choice for the ID column and better suited if you should use a sequence to generate the unique IDs.
I don't see any benefit in splitting the design into two tables.
我不了解动物饲养,但听起来你的 Sire_ID 是父亲,Dame_ID 是母亲? 没问题。 每只动物一行,购买的动物的 sire_ 和 dame_ID 为空,我预计不会出现任何问题。
等等。 您可能会在 while 循环中填充 TreeView 或 XmlNodeList...
在本例中,Animal.Children 是动物的集合。 因此,myAnimal.Children[0].Father 将返回 myAnimal。 .Parent[] 可以是其两个父级的集合,只要 [0] 始终是一个父级(父亲)而 [1] 始终是另一个(母亲),就应该可以工作。
将 ID 设置为自动编号 PK,并通过返回其父母的 ID 以编程方式分配 Sire_ID 和 Dame_ID。 不需要外键关系,但如果您确实愿意,两个父 ID 都可以引用回 ID。
I don't know about animal breeding, but it sounds like your Sire_ID is the father and Dame_ID is the mother? No problem. One row per animal, null sire_ and dame_ID's for purchased animals, I don't forsee any problems.
and so forth. You would likely populate a TreeView or XmlNodeList in a while loop...
In this case, Animal.Children is a Collection of Animals. Therefore, myAnimal.Children[0].Father would return myAnimal. .Parent[] could be a collection of its two parents, which should work as long as [0] is always one parent (father) and [1] is always the other (mother).
Make ID an Autonumber PK and assign Sire_ID and Dame_ID programatically by returning the IDs of its parents. No foreign key relationships should be neccessary though both parent IDs could reference back to ID if you really want to.
几个月前我在 MySQL 网站上问过类似的问题。 我建议您查看我从 Peter Brawley 收到的关于此类关系的回复:http ://forums.mysql.com/read.php?135,187196,187196#msg-187196
如果您想进一步研究该主题,那么我建议您查看维基百科上的树层次结构。
另一种建议的架构(将完全标准化)如下所示:
表:动物
ID | 名称 | 品种
表:谱系
animal_id | 父 ID | 父母类型(父亲或母亲)
I asked a similar question a number of months ago on the MySQL website. I would recommend that you take a look at the response that I received from Peter Brawley regarding this type of relationship: http://forums.mysql.com/read.php?135,187196,187196#msg-187196
If you want to research the topic further then I would recommend that you look into Tree Hierarchies on Wikipedia.
An alternate suggested architecture (that would be fully normalized) would look something like the following:
Table: animal
ID | Name | Breed
Table: pedigree
animal_id | parent_id | parentType (either sire or dame)
我认为您只使用一张桌子的布局就很好。 您肯定希望将 SIRE_ID 和 DAME_ID 保持与 ID 相同的数据类型。 您还希望将它们声明为 FOREIGN KEY(外键可以指向同一个表,并且外键也可以为空)。
使用这种布局,您可以轻松查找父代动物,还可以为给定动物构建后代树(对于 Oracle,有 CONNECT BY)
I think your layout using just one table is fine. You definitely want to keep SIRE_ID and DAME_ID in the same data type as ID. You also want to declare them as FOREIGN KEYs (it is possible to have a foreign key point back to the same table, and a foreign key can also be null).
Using this layout, you can easily look up the parent animals, and you could also build an offspring tree for a given animal (for Oracle there is CONNECT BY)
嗯,这是一种“正常”的一对多关系,您建议的方法是解决它的经典方法。
请注意,两个表是非规范化的(我无法准确指出 superkey-is-not-well-should-be subset-of-other-key-fsck-I-forgot 部分在哪里,但我很确定它就在那儿的某个地方); 直观的原因是第一个元组中的元组最多与第二个元组中的一个元组匹配,因此除非您有很多具有空父亲和母亲 ID 的动物,否则这在任何情况下都不是一个好的解决方案(它会降低性能 - 需要连接——并且不会减少存储需求)。
Well, this is a "normal" one-to-many relationship and the method you suggest is the classical one for solving it.
Note that two tables are denormalized (I can't point out exactly where the superkey-is-not-well-should-be-subset-of-other-key-fsck-I-forgot part is, but I'm pretty sure it's there somewhere); the intuitive reason is that a tuple in the first one matches at most a tuple in the second one, so unless you have lots of animals with null sire and dame IDs, it's not a good solution in any prospect (it worsens performance -- need a join -- and does not reduce storage requirements).