Можно ли уместить сложную логику в один запрос БД?

Question

[Serezhka]

Привет!
Я в образовательных целях делаю некоторую приложеньку.
Суть - есть автор, автор пишет пост, пост можно просмотреть другим и прокомментировать.
Посмотреть и прокомментировать могут либо все, либо определенные (зарегистрированные) участники объединенные в группы.
Задача - определить - можно ли показывать\принимать комментарии от конкретного пользователя.
(приложенька работает через REST, поэтому комментарии надо проверять отдельно от самого поста)

Примерная структура БД:
User
id | name | token

Post
id | text | authorID

Group
id | name | authorID

GroupUser
id | userID | groupID

PostAllowGroup
id | postID | groupID

Comment
id | text | authorID | postID

Дальше алгоритм такой:
1 получаем запрос от клиента с токеном и postID (на комменты)
2 идем в User и берем id которому соответствует токен
3 идем в PostAllowGroup и выбираем те groupID, в которых есть наш postID
4 идем в GroupUser и смотрим, есть ли поля где groupID соответствует userID из второго пункта
5 если все ок, то отдаем коммент(ы) по postID сделав JOIN c User по authorID

Можно ли всю эту логику уместить в один запрос к базе?
И будет ли это быстрее, чем делать много простых запросов?
Просто на данный момент мне ума хватает всю эту логику я реализовать цепочкой запросов (как в алгоритме)
База данных MySQL или Postgres
Спасибо!

Comments

[Владимир]

Можно использовать вот єтот инструмент чтобы расшаривать людям свои наброски sqlfiddle.com/#!17
В Постгри большой грамотно составленный запрос работает быстрее чем много маленьких, про MySQL не скажу.

[Serezhka]

Спасибо

Answer 1

[Danil Sapegin]

Моя практика показывает, что правильнее разбивать сложные запросы на несколько мелких с хорошо просчитанными индексами в БД. Такая схема зачастую работает быстрее.

Comments

[Вячеслав Успенский]

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

[Danil Sapegin]

Вячеслав Успенский, вы хотите сказать, что если в каждой таблице есть по паре миллионов записей, пара таблиц еще имеют логику "один-множество", все это дело мы сдабриваем JOINами и всё это будет работать быстрее, чем пара мелких запросов с быстрыми индексами?
Спорить на самом деле бесполезно, моя практика показывает, что тяжелые запросы в тяжелых проектах - боль и тоска.

[d-stream]

Danil Sapegin, даже в не очень оптимальном варианте отбор и отсечение join'ами не затронет такие медленные каналы как например отдачу еще не отфильтрованной выборки.

В приведенном ТС вопросе - это максимально выпячено, так как конечный ответ атомарный - да/нет и любые варианты получения нескольких выборок по 100500 строк с последующими манипуляциями над ними - захлебнуться еще на уровне их отдачи...

Ближайшая аналогия - не отдавать мобильному клиенту ужатую до 300*200 пикселей картинку, а отдать 38 мегапиксельную картинку и обрамить ее тэгами "показать 300*200" -)

[mafusailmagoga]

Вячеслав Успенский,

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

Вам бы следовало написать, "как правило".
Существуют ситуации, где отдельные запросы эффективнее. Такое не часто бывает. Но встречается. Как правило, это те ситуации, когда БД не заточена, когда это находится на границе её возможностей.

Например, реляционные БД плохо отрабатывают запросы с иерархией разной глубины или в WHERE конструкции с OR/IN, "не равно"

[Вячеслав Успенский]

mafusailmagoga, MySQL можно затолкать в угол достаточно просто и даже одним запросом. А более серьезные бд, как правило, эти моменты оптимизируют достаточно неплохо.

Answer 2

[d-stream]

Можно ли всю эту логику уместить в один запрос к базе?

да

И будет ли это быстрее, чем делать много простых запросов?

да

Comments

[Владимир Олохтонов]

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

[d-stream]

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

И авторизация - тут вообще не к месту. Ибо тут всего лишь ответ да/нет на пару userId и postId

Answer 3

[voronkovich]

Задача - определить - можно ли показывать\принимать комментарии от конкретного пользователя.

Это - задача авторизации пользователя (определение его прав). Не стоит смешивать ее с задачей извлечения данных (выборкой). Поэтому, с точки зрения архитектуры, лучше сделать хотя бы 2 запроса: первый - авторизация, второй - выборка.

И будет ли это быстрее, чем делать много простых запросов?

Это зависит от запроса. Но, в вашем случае, оптимизация - излишня, т. к. вы делаете приложение в образовательных целях.

В общем, на мой взгляд, несколько маленьких запросов - наиболее подходящий вариант для вас.

Answer 4

[Андрей]

Многое зависит от того как выставлены индексы и как напишете запрос. Если строк в таблицах много, если правильно выстроены индексы, и важна скорость выполнения, и не нужна наглядность самого кода(я так и не понял - сам запрос тоже в образовательных целях или только результат работы программы), то лучше писать в один запрос, естественно придётся его "полировать"(или переделывать запрос смотря на результат или смотреть "план запроса"). А если там строк немного и потом кто то будет смотреть/править Ваш код - то лучше писать небольшие запросы с комментариями.