Имеет и принадлежит многим против

Question

Это не другое, я должен использовать вопрос HABTM или HMT. Честный. Тем не менее, я собираюсь спросить, будут ли люди использовать HABTM или HMT в следующей ситуации.

• У меня есть модель "Книга".
• Хочу добавить модель "Автор". Автор имеет много книг. Книга имеет множество авторов.
• Хочу добавить модель "Тема". Тема имеет много книг. Книга имеет множество тем.

Я уже знаю разницу между двумя ассоциациями, знаю о таблицах объединения и знаю (в общем) преимущества каждой системы ассоциации.

Ясно, что здесь я могу установить два отношения HABTM.

Однако меня поразило, что я также могу быть остроумным и поместить свои foreign_ids в таблицу моделей «Книги», объявив авторов и темы как «has_many: авторы / темы,: через =>: книги».

У меня вопрос, думают ли люди, что это чрезмерная абстракция структуры базы данных, учитывая, что первичные отношения между BOOKS и AUTHORS, а также BOOKS и TOPICS и не являются прямыми отношениями между AUTHOR и TOPIC?

Другими словами, казалось, что, хотя я покончу с двумя (дополнительными) таблицами соединений и использую более гибкие отношения HMT, я могу разбавить точку моей базы данных, которая должна была хранить КНИГИ, которые затем связывают АВТОРАМ И ТЕМАМ.

Я подумал, что это довольно интересный вопрос.

Кроме того, все другие примеры использования HMT в Интернете, которые я мог найти, использовали таблицу «сквозного» как относительно незначительную часть базы данных. Например - использовать его в качестве «сквозной» таблицы для хранения оценок СТУДЕНТОВ, прошедших ИСПЫТАНИЯ; - хранить информацию о журнальных подписках ПОДПИСЧИКОВ, подписавшихся на ЖУРНАЛЫ.

Я никогда не видел пример, где таблица "сквозной" хранит первичную информацию. Похоже, что это больше для хранения вспомогательной информации о двух основных таблицах, к которым он присоединяется.

Answer 1

Как правило, подавляющее большинство людей из Rails предпочитает has_many через.Честно говоря, я думаю, что HABTM будет удален из Rails в следующих версиях.Использование через является более явным и менее подверженным ошибкам, и я настоятельно рекомендую использовать это вместо.Особенно, если вы впервые создаете таблицы соединений в Rails.

Теперь использование стороннего идентификатора для книг не очень хорошая идея.Вы пытаетесь связать множество со многими, используя две таблицы, и это очень плохая вещь для реляционных баз данных :) Вместо этого, со многими связями, придерживаться использования имеет много сквозных связей, что должно быть просто прекрасно.*

(между прочим, own_to_many не существует, для этого вам потребуется третья модель)

Answer 2

Я не могу делать то, что хотел; то есть, поместите таблицу соединений в КНИГИ. Почему бы и нет? Потому что, если я сделаю BOOKS таблицей соединений, у каждой книги будет ровно один «author_id» и ровно один «topic_id». Поскольку я хочу, чтобы в каждой книге было несколько авторов и несколько тем, мне некуда будет устанавливать эти отношения.

Причина, по которой это не работает, заключается в том, что HMT позволяет вам создать модель, которая может хранить дополнительную информацию о связи . В моей ситуации это были бы отношения между конкретным автором и конкретной темой.

Книга не является примером этих отношений.

Вместо этого мне понадобятся книги HMT для авторов и книги по темам. ТО Если бы я хотел сохранить дополнительную информацию об отношениях между автором и книгой, у меня была бы модель для ее хранения. Эта дополнительная информация могла бы быть:

• возраст автора, когда он написал
• сумма, заплаченная автору, чтобы написать это
• дата, когда автор закончил писать книгу

и в каждом случае вы можете видеть информацию, хранящуюся в модели HMT, относящуюся как к автору, так и к книге, к которой присоединяются (Таким образом, если бы у меня было несколько авторов, информация об авторе # 2 <-> книга была бы сохранена в отдельной модели HMT.)

Как указывал @ dasil003, вы можете обойти это и попытаться сохранить несколько связей в одном поле, но тогда вы, вероятно, не сможете присоединиться должным образом.

Answer 3

Я не знаю, что вы имеете в виду под словом "own_to_many: through Books", но и habtm, и hmt используют таблицу соединений.Если у вас есть отношения многие ко многим, от этого никуда не деться.Я не понимаю, как вы планируете хранить несколько авторов или тем на столе книг.Если вы объедините значения в одном поле, вы не сможете присоединиться к авторам или темам.Если у вас есть фиксированный максимум, вы можете добавить поле ассоциации для каждого из них, но в большинстве случаев это выглядит глупо.

Что касается примера первичных данных по отношениям hmt.Представьте, что вы предполагаете, что у каждой темы есть отдельная глава в книге (я ее придумал, но она соответствует вашей модели).Тема может быть отдельной главой в каждой книге.В этом случае вам нужно добавить поле главы в таблицу соединений и использовать hmt.