Rails, я ошибаюсь, что полиморфные ассоциации переоценены, ограничены и не нужны? - PullRequest
0 голосов
/ 11 сентября 2010

ОК, так что я занимался разными способами организации моих приложений на Rails 3 в отношении STI и Полиморфных Ассоциаций. Я пытался найти способ, который был бы и простым в написании кода, и простым в использовании, и с наибольшим шансом быть наиболее совместимым с любыми будущими изменениями. После прочтения большого количества необязательных (и часто недостающих и плохо написанных) статей я пришел к некоторым собственным выводам.

Во-первых, кажется, что использование STI - самая безопасная ставка с точки зрения простоты кодирования, удобства чтения и использования, а также простоты работы с любыми будущими изменениями без слишком большого переписывания. Единственный законный недостаток, который я вижу, это то, что в вашей БД будут «дыры» в данных. Некоторые люди думают, что это плохо. Но, ИМХО, если это единственный недостаток, и в результате вся оставшаяся жизнь станет чертовски легкой, то КТО ЗАБОЕТСЯ?

Во-вторых, кажется, что полиморфные ассоциации действительно хорошо работают только в определенных ситуациях, определенно не во всех ситуациях. Более того, кажется, что в любой ситуации, когда вы МОЖЕТЕ использовать Полиморфные Ассоциации, вы также можете просто использовать ИППП (и , а не наоборот). Так зачем вообще беспокоиться о полиморфных ассоциациях? Просто чтобы вытащить эти неприятные "дыры" из вашей БД? Но затем вы добавляете дублированные поля и дополнительные таблицы, которые очень похожи друг на друга, не говоря уже о множестве наборов контроллеров, моделей и представлений и т. Д.

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

Так вот, я не самый умный парень, так что это могут быть ошибочные и / или близорукие наблюдения. Пожалуйста, дайте мне знать, если вы считаете, что я неправ, и постарайтесь предоставить некоторые веские доказательства в поддержку вашего дела. !

1 Ответ

1 голос
/ 11 сентября 2010

Если бы я довел ваш аргумент до самого конца, я бы получил что-то вроде: зачем вообще беспокоиться о наличии нескольких таблиц базы данных? Просто используйте одну таблицу и STI для хранения всех ваших данных.

Дополнительно рассмотрим приложение для книжного магазина с авторами, издателями, книгами и пользователями. Представьте, что у пользователя есть возможность подписаться на уведомления по электронной почте об изменениях для любого из авторов, книг или издателей. Для этого можно создать таблицу notifications. Эта таблица хотела бы иметь полиморфную ассоциацию с любым из объектов, за которыми можно следовать. Как бы вы структурировали это более четко с помощью STI?

...