P
вроде там требовался алфавитный порядок
Size: a a a
2020 January 09
VA
Paul
вроде там требовался алфавитный порядок
Да, конечно в алфавитном порядке. Просто в 2к20 юзать habtm это ваще печаль. Я сам лет 10 не использую вот и забыл.
P
я периодически пользуюсь — именно там, где он нужен. таких кейсов очень мало, конечно, но они бывают.
VA
Paul
я периодически пользуюсь — именно там, где он нужен. таких кейсов очень мало, конечно, но они бывают.
Ну даже когда они есть, лучше сразу сделать has_many through, потому что из минусов только добавление колонки
id в таблицу. А вот плюсы - всё оставльное. У тебя появляется связная модель, на неё можно всякие скоупы делать (если понадобится). Ну и расширять в дальнейшем.P
ну вот у тебя ключевое тут "если понадобится" и "расширять в дальнейшем" :) обычно этого ничего не нужно, просто мелкая связь и всё
T
Согласен с Paul) в реальных ком проектах такие дополнительные связки используются редко
VA
Paul
ну вот у тебя ключевое тут "если понадобится" и "расширять в дальнейшем" :) обычно этого ничего не нужно, просто мелкая связь и всё
Да, это попахивает преждевременной оптимизацией. Но ещё раз - даже если в ТЗ нет доп. полей, то в дальнейшем они появляются. И приходится вообще всё переделывать :-/
А так - появляется модель, есть пить не просит.
А так - появляется модель, есть пить не просит.
T
Ну это не просто модель, это доп таблица в базе, и когда у тебя сотня реальных таблиц, то каждая есть не просит может внести большую путаницу. Лучше писать по факту
T
Темболее что такие таблицы мало на что влияют, можно и без них все доставать с третьих и четвертых вложенных таблиц
T
Не вложенных, не так выразился, взаимосвязанных
P
Ну это не просто модель, это доп таблица в базе, и когда у тебя сотня реальных таблиц, то каждая есть не просит может внести большую путаницу. Лучше писать по факту
вот да, писать по факту это оч полезное дело. очень часто хочется улучшить, обобщить, добавить что-то на вырост — а результате этим так никто никогда и не воспользуется.
VA
Ну это не просто модель, это доп таблица в базе, и когда у тебя сотня реальных таблиц, то каждая есть не просит может внести большую путаницу. Лучше писать по факту
И как же это путаницу внесёт? В бд таблицы всё-равно будут. А то, что в папке с моделями доп. файлы появляются - в принципе не правильный подход для больших проектов. Надо использовать неймспейсы, чтобы делить на что-то типа доменов
T
В бд таблицы только реальные, нет ничего про запас
P
я так считаю — надо понимать плюсы/минусы обоих подходов, а уж решать по месту, что именно юзать, руководствуясь правилом не плодить сущности без нужды.
VA
Paul
вот да, писать по факту это оч полезное дело. очень часто хочется улучшить, обобщить, добавить что-то на вырост — а результате этим так никто никогда и не воспользуется.
Писать по факту - это переписывать в дальнейшем. Я сейчас не про конкретной этот случай говорю. Про много случаев. Сильно заморачиваться смысла нет, но оставить пути отхода для дальнейших тасок - почему бы и нет
T
Какие пути отхода? Отсюда вопрос - вы работаете с ком проектами?
P
все упирается в деньги владельца продукта. я считаю, что не стоит тратить их на решение проблемы, которая может никогда не возникнуть. если бы я писал код для себя забесплатно, то может и делал бы с кучей штук на вырост
T
Так таких путей можно написать на каждую вторую модель, в реальных проектах практически все модели имеют какие либо ассоциации, а бывает и с десятком моделей одна может взаимодействовать
VA
Так таких путей можно написать на каждую вторую модель, в реальных проектах практически все модели имеют какие либо ассоциации, а бывает и с десятком моделей одна может взаимодействовать
Вот в реальных проектах как раз и бывает такое, что ставят задачу: Хотим чтобы к статье была возможность добавлять тэги.
А потом (через год) появляется задача: Хотим эти тэги категоризировать в зависимости от статьи (ну или ещё какая муть). И человек ходит по проекту и мучается переписывая habtm на Has_many through
А потом (через год) появляется задача: Хотим эти тэги категоризировать в зависимости от статьи (ну или ещё какая муть). И человек ходит по проекту и мучается переписывая habtm на Has_many through
VA
Paul
все упирается в деньги владельца продукта. я считаю, что не стоит тратить их на решение проблемы, которая может никогда не возникнуть. если бы я писал код для себя забесплатно, то может и делал бы с кучей штук на вырост
Да нет большой разницы написать в самом начале has_many through и создать таблицу. А вот в дальнейшем это же действие займёт больше времени