拥有并属于许多人 vs. 拥有许多人
这不是另一个“我应该使用 HABTM 还是 HMT”问题。诚实的。也就是说，我要问人们在以下情况下是否会使用 HABTM 或 HMT。
- 我有一个模型“书”。
- 我想添加一个模型“作者”。一个作者有很多书。一本书有很多作者。
- 我想添加一个模型“主题”。一个主题有很多本书。一本书有很多主题。
我已经知道这两个关联之间的区别，我了解连接表，并且我（通常）知道每个关联系统的好处。
显然我可以在这里建立两个 HABTM 关系。
然而，令我震惊的是，我也可以机智地通过将作者和主题声明为“has_many :authors/topics, :through => :books”，将我的foreign_ids放入“Books”模型表中。
我的问题是，鉴于主要关系是 BOOKS 和 AUTHORS、BOOKS 和 TOPICS 之间，而不是 AUTHOR 和 TOPIC 之间的直接关系，人们是否认为这是对数据库结构的过度抽象？
换句话说，虽然我放弃了两个（额外的）连接表并使用更灵活的 HMT 关系，但我可能会淡化数据库的意义，即存储书籍，然后链接到作者和主题。
我觉得这是一个比较有趣的问题。
此外，我在互联网上找到的使用 HMT 的所有其他示例都使用“通过”表作为数据库中相对不重要的部分。例如 - 将其用作“直通”表来存储参加测试的学生的成绩； - 存储有关订阅杂志的订阅者的杂志订阅信息。
我从未见过“通过”表存储主要信息的示例。它似乎更多地用于存储有关它连接的两个主表的辅助信息。
This isn't another should I use HABTM or HMT question. Honest. That said, I am going to ask whether people would use HABTM or HMT in the following situation.
- I have a model "Book".
- I want to add a model "Author". An Author has_many Books. A Book has_many Authors.
- I want to add a model "Topic". A Topic has_many Books. A Book has_many Topics.
I already know the difference between the two assocations, I know about join tables, and I know (generally) the benefits to each association system.
Clearly I can set up two HABTM relationships here.
However, it struck me that I could also be witty and put my foreign_ids in the "Books" model table by declaring Authors and Topics as "has_many :authors/topics, :through => :books".
My question is whether people think this is an over-abstraction of the database structure, given that the primary relationship is between BOOKS and AUTHORS, and BOOKS and TOPICS, and is not the direct relationship between AUTHOR and TOPIC?
Put another way, it seemed that while I get to do away with two (extra) join tables and use the more flexible HMT relationship, I might be diluting the point of my database, which was to store BOOKS, which then link to AUTHORS and TOPICS.
I thought this was a relatively interesting question.
Also, all the other examples on the Internet I could find of the use of HMT used the "through" table as a relatively insignificant portion of the database. For example
- using it as a "through" table to store grades of STUDENTS who took TESTS;
- to store info about magazine subscriptions of SUBSCRIBERS who subscribed to MAGAZINES.
I've never seen an example where the "through" table stores primary information. It seems to be more for storing ancillary information about the two main tables that it joins.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不知道“belongs_to_many：通过书籍”是什么意思，但 habtm 和 hmt 都使用连接表。如果您存在多对多关系，则无法摆脱它。我不明白您打算如何在图书表上存储多个作者或主题。如果将值组合在单个字段中，您将无法加入作者或主题。如果您有固定的最大值，您可以为每个字段添加一个关联字段，但在大多数情况下这似乎很笨拙。
至于 hmt 关系上的主要数据的示例。想象一下，您假设每个主题在一本书中都有一个特定的章节（我知道这是人为的，但它适合您的模型）。该主题可能是每本书的不同章节。在这种情况下，您需要将章节字段添加到连接表并使用 hmt。
I don't know what you mean by "belongs_to_many: through Books", but both habtm and hmt use a join table. If you have a many-to-many relationship there's no getting away from it. I don't understand how you plan to store multiple authors or topics on books table. If you combine the values in a single field you won't be able to join the authors or topics. If you have a fixed maximum you could add an association field for each one, but that seems kludgy in most cases.
As for an example of primary data on a hmt relationship. Imagine that you were assuming that each topic had a specific chapter in a book (contrived I know, but it fits your model). The topic might be a different chapter in each book. In that case you would need to add the chapter field to the join table and use hmt.
一般来说，绝大多数 Rails 人更喜欢通过 has_many。说实话，我认为 HABTM 将在未来的版本中从 Rails 中删除。使用 through 更明确且不易出错，我强烈建议您改用它。特别是，如果这是您第一次在 Rails 中创建联接表。
现在，在书籍上使用外国 ID 并不是一个好主意。您可能会尝试使用两个表进行多对多关联，这对于关系数据库来说是一件非常糟糕的事情:)相反，对于多对多关联，坚持使用 has many through ，这应该没问题。
（顺便说一句，belongs_to_many 不存在，您需要第三个模型才能做到这一点）
Generally, the vast majority of Rails people prefers has_many through. To tell you the truth, i think that HABTM will be removed from Rails in the versions to come. Using through is more explicit and less error prone and i strongly suggest that you use that instead. Especially, if this is the first time you create join tables in Rails.
Now, using a foreign id on books is not a good idea. You would be trying to make a many to many association using two tables and that is a very bad relational databases thing to do :) Instead, with many to many associations, stick to using has many through, that should be just fine.
(btw, belongs_to_many does not exist, you would need a third model to do that)
我不能做我想做的事；即把连接表放在BOOKS中。为什么不呢？因为如果我将 BOOKS 设置为连接表，则每本书将只有一个“author_id”和一个“topic_id”。由于我希望每本书能够有多个作者，每本书有多个主题，因此我将无处放置这些关系。
这不起作用的原因是 HMT 允许您创建一个可以存储有关关系的附加信息的模型。在我的情况下，这将是特定作者和特定主题之间的关系。
一本书不是这种关系的一个例子。
相反，我需要 HMT 书籍到作者，书籍到主题。 那么如果我想存储有关作者和书籍之间关系的附加信息，我会有一个模型来存储它。附加信息可能是：
，在每种情况下，您都可以看到存储在 HMT 模型中的信息对于作者和所加入的书籍都是特定的。 （因此，如果我有多个作者，有关作者#2<->书的信息将存储在单独的 HMT 模型中。）
正如 @dasil003 指出的，您可以围绕这一点进行拼凑并尝试在一个字段中存储多个关系，但这样您可能无法正确加入。
I cannot do what I wanted to do; that is, put the join table in BOOKS. Why not? Because if I make BOOKS the join table, each book will have exactly one "author_id" and exactly one "topic_id". Since I want to be able to have multiple authors per book and multiple topics per book, I will have nowhere to place those relationships.
The reason why this doesn't work is that HMT allows you to create a model that can store additional information about a relationship. In my situation, that would be the relationship between a specific author and a specific topic.
A book is not an instance of this relationship.
Instead I'll need to HMT books to authors, and books to topics. THEN if I wanted to store additional information about the relationship between an author and a book, I'd have a model to store it in. That additional information might be:
and in each case you can see the information stored in the HMT model is particular to both the author and the book being joined. (So if I had multiple authors, the information about author #2<->book would be stored in a separate HMT model.)
As @dasil003 pointed out, you could kludge around this and try to store multiple relationships in one field, but then you'd probably not be able to join properly.