Где вы храните запросы к базе в коде или используйте хранимые процедуры?

Question

[Рустам .]

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

Comments

[Vitaliy K]

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

[ThunderCat]

Vitaliy K,

В процедурах удобство в том, что не загромождается код проекта,

угу, все загромождается в базе, в которой разберется только хороший ДБА. И если придется что-то менять - без отдельного спеца вообще не обойтись. Мочу о том что в итоге код все равно придется переписывать. Только теперь понадобится не один спец, а два. Ну и "загромождается" - слишком громко сказано, все достаточно хорошо структурируется на уровне репозитория и орм.

[Олег]

Можно уточнить ? Вы фреймворк какой либо используете ?
Понятия router,controler,model,view знаете ?
Правильно когда запросы выполняются только в модели.
При этом модель не тупая обертка над таблицей, а более интеллектуальная вещь.

[Alex Wells]

Олег,

а более интеллектуальная вещь.

ват?

запросы выполняются только в модели.

ват? Модель вообще не должна быть никакой оберткой, и никаких запросов и в помине выполнять не должна. Это тупая сущность с геттерами и сеттерами. Максимум - еще какие-то доп. фишки но ТОЛЬКО если она закрыта каким-то интерфейсом.

[ThunderCat]

Олег,

При этом модель не тупая обертка над таблицей, а более интеллектуальная вещь.

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

[Олег]

Alex Wells, а вы сейчас не класс сущности описали ?

[Олег]

ThunderCat, угу и мы такую видим в codeigniter CI_Model, и его построитель запросов,
имеет глобальную видимость. Можем словить куски мусора , если разработчик решил не звать гет, инсерт и т.д.
и не почистил его явно через reset_query().

[ThunderCat]

Alex Wells,

Модель вообще не должна быть никакой оберткой

У вас какое-то усеченное понимание модели. Модель это не класс, модель это сущность. Модель может содержать достаточно много классов, в частности репозиторий - как часть модели.
читать например тут

[ThunderCat]

Олег, Мы такую много где видим, суть в том что для проекта в 3 странички и 2 таблички оно канает, но как только появляется хоть какая-то существенная внутренняя логика весь профит от простоты такого подхода теряется.

[Олег]

ThunderCat, самое неприятное, что такая простота, типа просто обертка для построения запроса, провоцирует
juce code , ладно еще в контролере , так и во вьюхах в базу лезут

[Alex Wells]

ThunderCat, мы говорим о модели данных. Обычной тупой сущности. Каким образом модель может относится к репозиторию (не наоборот)?

[Alex Wells]

Олег, обозначьте термин "класс сущности".

[ThunderCat]

Alex Wells,

мы говорим о модели данных

Кто это "мы" и где вы это прочитали? Разговор идет о MVC, именно в том что касается паттерна и роли Model в нем.

Обычной тупой сущности.

"Это дубли у нас п-п-ростые"(с). Все, что вы себе напридумывали - сугубо ваше личное дело, "модель это класс" - распространенное заблуждение, увы, часто реализуемое на практике.

[Олег]

Alex Wells, https://www.doctrine-project.org/projects/doctrine...

если абстрагироваться от доктрины
/** var $result MyEntityClass[] **/
$result = $STH -> fetchAll();

где MyEntityClass может быть просто фиктивно описан для среды разработки, т.е
работать будем со стандартным stdClass для скорости, а в разработке поимеем все плюшки подсказок и автозавершения ввода

[Alex Wells]

Олег, и везде писать аннотации? И о какой скорости идет речь, лол? Скорости создания обьекта с нормальными полями vs скорости создания магического обьекта с непонятным набором данных?

И ->fetchAll() есть паттерн ActiveRecord - отличная штука для маленьких проектов, конечно, но далеко не панацея. Это, если что, полная противоположность доктриновского datamapper'а.

[Alex Wells]

ThunderCat, каком MVC? С чего то вы взяли, что разговор идет об MVC? MVC сам по себе сейчас не используется нигде. Ни в одном крупном проекте или фреймворке вы не найдете MVC в общепринятом его проявлении.

"модель это класс"

Что за "модель это класс"? Я такого не говорил и не понимаю, о чем речь. Да, модель может быть классом. Дальше что?

Все, что вы себе напридумывали - сугубо ваше личное дело

SOLID, значит, придумал я?) Ну хорошо)

[Олег]

Alex Wells, не приведи вам господи суппортить легаси.
https://github.com/Muraveiko/codeigniter-phpstorm/... (спасибо большое natanfelles от которого я форкнул)
вот костыль и обвесы по типу как показал выше позволяют с ним хоть как-то разобраться.
В результате код в шторме удается позеленить, вместо сплошных красных подчеркиваний.

[Alex Wells]

Олег, ну это такое себе решение. Поддерживать плагин, отказываться от статического анализа, не иметь никакой возможности мигрировать код на другую платформу/язык.. Всегда прийдется идти на компромисы, конечно, но есть компромисы дающие вам более гибкий код/архитектуру, при этом удешевляя поддержку, а есть и такие)

Answer 1

[DevMan]

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

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

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

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

Comments

[ThunderCat]

Сергей Некий,

Процедуры не только более быстры, но и более гибки.

Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное, а у нас денег нет! (с) Это я к тому что чтобы процедура была реально гибкой и быстрой, нужно иметь нехилый скилл в чистом SQL и достаточно глубокие знания конкретной БД, чем не каждый ДБА может похвастаться. В случае переноса логики в код даже средний программист легко напишет логику выборки на ОРМ. То есть вместо 2 спецов с квалификацией выше среднего + средний, нужен один средний. Причем как для разработки, так и для поддержки.

[d-stream]

Для более-менее разлапистой логики, подразумевающей транзакции - выносить транзакции с уровня "атомарных" stored procedures (процедура меняет множественно данные в куче таблиц в трамках транзакции) на уровне приложения реализовывать такое - гораздо сложнее.

а переписывать и тестировать процедуры в субд проще?

вообще-то проще. И чаще всего изменения затрагивают именно этот слой - структура базы и процедуры, а вот "внешнее проявление" (вызов процедур) - остается неизменным.

Естественно все это скорее из серии споров про то с какой стороны разбивать яйцо и долгих споров и войн не стоит)

[ThunderCat]

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

Все что не особо то и трудно - легко пишется запросами без хранимок и не сильно при этом проседает. И все это в 99% в хранимках не нуждается. А все что реально сложно - не каждому по силам написать. Иначе профессия ДБА уже давно спукнулась бы. Молчу что есть специфичные вещи а-ля оракл и прочие экзотические вундервафли, где сложность такой задачи совсем другая, ибо специфику надо знать.

[Arris]

Сергей Некий, о скиллах, которых нет у джуна, очевидно ;)

[ThunderCat]

Сергей Некий, Если честно - вообще не понимаю - о чем спор? 2 хранимки на проект где они реально нужны - без вопросов. Все остальное легко покрывается логикой ОРМ или запросами из репозиториев, буде таковые нужны в чистом виде и орм не справляется. Изначально вопрос стоял - "хранить все запросы в виде сторед или вынести в код?". Ответ - хранить в коде, так как не нужно каждый раз лезть в 2 места если логика меняется, не размазывается поведение на 2 аппликации, и все легко отслеживается в вершн контроле. Я по тому и писал что запросы покрывают 99% логики общения с бд. Сложные вещи, требующие логики в бд встречаются крайне редко, даже в крупных проектах.

[DevMan]

d-stream,

вообще-то проще. И чаще всего изменения затрагивают именно этот слой - структура базы и процедуры, а вот "внешнее проявление" (вызов процедур) - остается неизменным.

рили? даже если добавились новые поля?

Сергей Некий, если бы был только один подход с железобетонными доводами в плюс, других бы не существовало.
веб можно писать на сях (других компилируемых языках), но предпочитают писать на интерпретируемых, невзирая на просадку по скорости; максимум - вынос особо тяжелых мест на компилятор или перенос части логики в СУБД.

[DevMan]

Сергей Некий, увы, вы не уловили суть моего комента.

[Сергей c0re]

ThunderCat, DBA код не пишет, это администратор БД
код пишут программисты БД и они вовсе не DBA

[Сергей c0re]

ThunderCat,

Ответ - хранить в коде, так как не нужно каждый раз лезть в 2 места если логика меняется, не размазывается поведение на 2 аппликации, и все легко отслеживается в вершн контроле

1. относительно БД, в нормальных случаях, весь код лежит в тех же CVS и все отслеживается, рефакторится и т.д.
2. подумайте, почему энтерпрайз до сих пор хардкодит в БД? может потому, что это и есть "в одном месте"? а из клиента дергается ТОЛЬКО процедуры. надо менять логику, перерписываете запросы В бд, в процедурах, процедуры.
3. есть приложения которые ПОЛНОСТЬЮ находятся в БД, а клиентское приложение наподобие браузера (тонкий клиент) в нем вообще никакой логики нет, кроме как XML в UI переводить.

[ThunderCat]

Сергей,

подумайте, почему энтерпрайз до сих пор хардкодит в БД?

По тому что это в большинстве случаев не так? Я как бы работал с несколькими конторами, поддерживающими весьма крупные проекты, в том числе на оракле + ява, и на С++ + МССкуль, никто уже давно не хранит код в процедурах. Во первых неудобно, во вторых сейчас многие системы имеют не одно хранилище, что делает размазывание кода еще больше при хранении кода в бд. Пару хранимок вполне нормально, там где критично быстродействие. Остальное в коде.

есть приложения которые ПОЛНОСТЬЮ находятся в БД, а клиентское приложение наподобие браузера (тонкий клиент) в нем вообще никакой логики нет, кроме как XML в UI переводить.

Есть, и тут имеет смысл хранить все в одном месте. Как бы логично. Но опять же, это не тот случай что у ТС.

код пишут программисты БД и они вовсе не DBA

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

В моей практике в 2 проектах было решено "хранить в процедурах". В первом случае - МССКУЛ (2005 год), от которого в итоге отказались в пользу мускуля, и все написанные процедуры пошли по бороде, и в итоге все легло в код. Второй - ЦРМ (2012), до сих пор жива, правда обслуживают ее ребята которые каждый раз при запрашиваемых изменениях от руководства вспоминают добрым словом нашего архитектора приложения. В общем - не удобно это, иногда оправдано, но поддержка в разы сложнее и геморнее.

[Сергей c0re]

ThunderCat, я наоборот не встречал энтрепрайза вне БД, так же как и не встречал программистов DBA или наоборот, (первые пишут код не чтобы быстрее работало, а чтобы быстрее написать ))), вторые его вообще не пишут и не понимают в бизнеслогике), это слишком ШИРОКАЯ область, особенно для Oracle и MS SQL
текущий проект, который поддерживаю, он правда древний, Oracle (полностью все в хранимках. включая вывод XML на клиента) + тонкий клиент на C#
на сколько мне известно софт Спортмастера, написанный тем же разработчиком, работает по аналогичной схеме и большинство их проектов.
так же крупнейшие депозитарии РФ, не буду называть (возможно ком. тайна :) ))
один Oracle (все операции в хранимках) + клиент Java (Spring+Hiberbate) + еще куча всего
другой MS SQL (все операции в хранимках) + клиент ... Delphi !! )))
и большинство банковского софта в хранимках. более того не в хранимках а в пакетах (это если Oracle, ну это условно можно считать классами ))) )
нормально все поддерживается, правда в случае с денежными операциями, без доступа к живым данным или среза, работать порой печально - трудно ))
потому как код практически неначем проверить.

Answer 2

[FanatPHP]

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

Если отвечтаь на вопрос буквально, то

1. Для большинства простых операций с БД запросы вообще не пишутся, пишутся обращения к ORM. Например в вместо

$stmt = $pdo->prepare("SELECT * FROM users WHERE id=?");
$stmt->execute([$id]);
$user = $stmt->fetch();

Пишется

$user = $em->getRepository(User::class)->find($id);

2. Сложные запросы с фильтрами лежат в специальных классах, которые называются репозиториями.

Comments

[Рустам .]

2. Сложные запросы с фильтрами лежат в специальных классах, которые называются репозиториями.

Можно поподробней?

[FanatPHP]

В каком смысле подробней?

[Lander]

Рустам ., https://habr.com/ru/post/248505/

[Рустам .]

FanatPHP, что такое репозиторий связи с запросами, примеры, статьи .
Спасибо.

[FanatPHP]

Ну просто класс в котором лежат методы каждый метод выполняет один сложный запрос

[Рустам .]

FanatPHP, спасибо

[Arris]

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

Неправда ваша. Неправа в том, что не используются.

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