Плюсы и минусы наследования единой таблицы для активов в Rails - PullRequest
4 голосов
/ 16 января 2012

Я смотрю на гемы загрузки файлов, и, похоже, наблюдается тенденция складывать все активы в одну таблицу «Активы» и использовать STI для их подкласса. Как ImageAsset, VideoAsset, AudioAsset и т. Д.

Я новичок в Rails и никогда не использовал STI. Ранее я бы просто сделал images, videos, audios отдельные таблицы. Конечно, они могут иметь несколько столбцов, но я бы сказал, что они также будут иметь несколько разных столбцов (например, частота дискретизации не относится к изображению)

Плюсы объединения всего этого в одну таблицу «ресурсов»: проще выполнять запросы ко всем активам. Минусы: стол станет больше быстрее. Я думаю, я всегда мог осколок столбца "type", если это проблема. Также я ожидаю, что все столбцы, содержащие только звук, будут пустыми в строках изображения и т. Д.

Все мое приложение будет основано на активах, поэтому я хочу убедиться, что у меня есть свои плюсы и минусы прямо перед принятием решения. Кто-нибудь сделал активы ИППП и пожалел об этом? Кто-нибудь сделал это и не пожалел об этом (за большое количество активов)? Будет ли CTI (наследование таблиц классов) лучшим решением?

1 Ответ

6 голосов
/ 16 января 2012

Я бы сказал, что одним из самых больших минусов использования STI является то, что если вы когда-нибудь добавите в таблицу столбец, который не является общим (и что это означает одно и то же) между ВСЕМИ моделями STI, то вы 'Мы просто взорвали вашу целостность данных.

Нулевые поля в (реляционных) базах данных обычно вызывают больше проблем, чем решают.

Я был укушен этим пару раз, и это особенно расстраивает, когда у классов в вашем отношении STI появляются собственные подклассы, которые, в свою очередь, добавляют еще больше столбцов в таблицу.

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

В верхней части моей головы я могу просто подумать об одном сценарии, где STI может быть разумным, и именно тогда вы имеете дело с моделями транзакций (например,депозиты и снятие средств с банковского счета или около того).В этих случаях обе модели по сути одинаковы, за исключением «направления» транзакции.

Можно также утверждать, что STI «хорош» для быстрого прототипирования, и если вы просто хотите что-то поставитьвместе fast просто чтобы посмотреть, работает ли он вообще, вы можете использовать STI, но как только вы начнете добавлять столбцы, которые не имеют смысла для всех моделей в отношении, вывероятно, следует преобразовать его в CTI или что-то еще.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...