RoR быдлокод

Так зачем писать свой метод, если можно написать User.find(user_id).news. А в моделях будет User has_many news; New belongs_to user??
ЗЫ: Или может я не понял чего-то из вашего объяснения?

Тогда больше подходит News.find(бла-бла, то, что нужно в запросе).user.

обычно так и делают: news#index вызывает не News.all, a кастомный метод/скоуп модели news или user. ничего особо страшного нет.

В RoR предлагается делать модели на каждую таблицу в бд, по крайней мере так во всех учебниках, но в 90% случаев выборка делается не по одной таблице а по 2-3

Добро пожаловать в мир ORM с его страшными model relationships.

Эм, у тебя News должен быть belongs_to :user, в #index делаешь как обычно News.all и во вьюхе показываешь news_item.user, если нужно получить автора новости? Или в чём проблема?

ты так получишь n+1 запросов на каждый хит

Берешь и кешируешь. Или можно получать сразу всё нужное с помощью скоупов: http://www.dahliabock.com/blog/2012/01/25/activerecord-n-1-queries-problem/

Как это решается я в курсе)

Про новости это просто пример чтоб понятно было о чем я.
В реальных ситуациях может быть, что нибудь вроде:
Нужно получить 20 новостей отсортированных по дате последнего коммента к новости + информацию о пользователе добавившем новость + например, количество новых комментов со времени последнего чтения новости авторизовавшимся пользователем.
Там 4-5 таблиц получается. Я в возможностях Связей Active Record еще не силен но имхо проще sql запрос написать или вообще функцию в бд которая все это будет собирать.

обычно так и делают: news#index вызывает не News.all, a кастомный метод/скоуп модели news или user. ничего особо страшного нет.

Ну я про то, что будет например таблицы news, users. Контроллер mainpage и модель mainpage которая будет работать с таблицами news и users. И в моделе mainpage метод getnews.

Как то так.

Писать свой sql запрос как-то не rails-way. Лучше изучите связи. Вот хороший материал, хотя наверное и так читали. И тут вам советовали использовать scopes. Наверное я закапитанил, ну да ладно.

Да читал и то и другое, просто когда дело доходит до сложных запросов, как это сделать на sql с ходу могу сказать, а чтоб понять как это делается средствами ror приходится убить кучу времени. Но это мои личные проблемы, тред немного о другом.

Все твои проблемы отлично решаются в рамках ORM. Просто надо привыкнуть, тогда не придется убивать кучу времени :)

Делай все с помощью орм, не принуждай последователей твоего кода к файспалму..)

Это очень редкая ситуация, когда невозможно обойтись средствами орм, я с такой не сталкивался. Сложные запросы вообще с моей т.з. неверный путь, т.к. они требовательны к ресурсам.

и кстати гид довольно исчерпывающий помоему
http://guides.rubyonrails.org/association_basics.html
http://guides.rubyonrails.org/active_record_querying.html

Рельсы не для таких простых вещей. Даже если кажется что то криво, всё равно пиши: существует масса более кривых, но тем не менее полезных особенностей.

Причем тут RoR? Вы с самого начала придумываете себе костыли :) Еще более лучшим вариантом будет выкинуть sql и писать все новости в redis, тогда вообще не придется задумываться о многих моментах. Но что, если у вас появются теги? И нужно будет много и сложно сортировать эти данные? А потом у Авторов появются какие-нибудь книги, или лог-рейтинга?

Короче, простое правило - с самого начала делаем максимально просто и стараемся не ломать представление реальных сущностей (новость есть новость, автор новости - автор), а вот когда у вас уже будет 30000rps - тогда можете начать с кеша, а потом уже убрать джойны.

А как иначе? Видел я не-орм-ные схемы баз, это тихий ужас, особенно стоит кастрировать любителей id-шек с custom-неймингом :) аля nid/did/xuid

У тебя проблема в том, что тебе кажется, что 4 операции = это много. В действительности их там гораздо больше. Поверь мне, чтобы действительно понимать, вреден ли джойн в данном случае - возьми explain и проверь им. Неожиданно ты обнаружишь, что чтобы трахнуть базу джойном нужна таблица пожирнее, чем таблица новостей, тегов и комментариев. Что тебе мешает в таблице новостей записывать last_comment_created_at? Вот тебе уже - 1 джойн.

Кол-во новых комментов то тут вообще причем?

Вообще-то я имел ввиду то, что большинство (и каждая вменяемая) ORM выборку любых relations обеспечивает из коробки простым и понятным способом. И объявление этих relations тоже, кстати.

Чувак, ты давно школу закончил? То ты доказываешь, что в Ruby надо все манкипатчить, и сто mixin - это решение всех проблем, то теперь предлагаешь ORM и только ORM использовать.

Что то мне кажется, что я тебя даже бложик разрабатывать не взял, не то что действительно сложное приложение.

В твоем мире вообще существуют задачи со сложной взаимосвязью? Или ты боишься руки замарать SQL вставкой или правильным составлением JOIN?

Ну и ты в курсе, да? Что ORM - лишь каркас, но вписывая себя в ее ограничения, обходя сложные запросы и не пытаясь думать, как оптимизировать базу, и почему твой JOIN вешает базу - ты никуда не уедешь?

Ну, прежде всего я рад, что у меня появляются фанаты, которые следят за моими постами, очень польщен, честно.

Не пойму как связаны monkeypatch и ORM (SQL вставка - это не monkeypatch, чтобы ты знал).

Кстати в руби не принято использовать monkeypatch.

Динамические возможности руби никак не связаны с monkeypatch (если ты об этом). Это называется метапрограммирование, и мне нравится метапрограммирование, я использую его постоянно, т.к. в ruby есть все для этого. И этого мне не хватает в других языках, например в js.

monkeypatch это небольшое изменение исходного кода, для удовлетворения насущных потребностей, кстати, тут один адепт питона говорил, что это нормально (изменить код в исходной библиотеке), так что по вопросам monkeypatch - к нему, он назвал это «обычный патч»))

Но, допустим, тебе нужно изменить функционал определенного класса, который не попал под делегирование, тогда, приходится расширять класс с помощью модуля(ей). При этом можно сделать красивую конструкцию для подобных задач, легко подключающую и отключающую изменения. Т.е. в ruby есть много инструментов, как раз приходящих из метапрограммирования. Например можно сделать hook метода вообще не изменяя его. И естественно все стараются обойтись без этого.

Возвращаясь к теме SQL вставок, просто, для начала надо убедиться, что нельзя обойтись без них. А если вдруг окажется что нельзя, то, стоит подумать, правильным ли путем ты идешь.

Сложно-ложно.

А главное, то, что перечислил TC отлично вписывается в возможности ORM. А рассуждать гипотетически можно сколько угодно.