Почему нельзя/можно писать бизнес-логику в sql?

Question

[alexeyshkolnik]

Вопрос по архитектуре: очень часто слышу, что нельзя БЛ писать в SQL. Хочу понять почему. Аргумент о том, что будем менять БД не подходит, БД менять ближайшие 10 лет не собираемся.
Вижу минус: в БЛ опираемся на сущности БД, но это не страшно или нет?
Плюсы: очень просто вносить изменения - затрагивается только один слой - база данных, и минимальные или вообще никаких изменений на фронте.

Comments

[Александр Маджугин]

С моей точки зрения чем лучше ваша БД отражает объектную область, тем меньше вам нужно описывать БЛ вообще. Т.е. описание БЛ это неизбежное зло из-за ограничений БД которая не может отразить реальность максимально точно. При этом перенос части БЛ в модель, в БД в конечном итоге это не плохо - это хорошо.
Но только если ваши запросы не превращаются в уродские и остаются читаемыми, а данные остаются нормализованными.
Плохой признак когда перенос БЛ в БД требует денормализации или таблицы/запросы выходят некрасивыми/нечитаемыми. Это плохой признак - тут надо остановиться и вынести логику в контроллер.
По сути красота, читаемость кода и нормализация данных всё что должно вас интересовать.

Answer 1

[mayton2019]

Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
бизнес логики из 20-го века.

В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
даже заменяемым на другие типы баз.

Но не все так плохо.

Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
есть какая-то минимальная логика, например при аутентификации или при проверке
валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
Потому что агрегировать в приложении все - глупо. Это лишний трафик.

И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.

Comments

[alexeyshkolnik]

mayton2019, можно поподробнее про две копии логики? (Есть свои мысли, но прежде хочу услышать ваши).
Orm - это отдельная песня, с одной стороны ты получаешь удобство доступа к данным, с другой ад в профайлере , но это офтоп.

[mayton2019]

Ну логика может быть реализована не только в виде conditions. Это может быть некое знание
о том какие есть таблицы и какие констрейнты. Если в базе были триггеры - то как их учесть
во всех остальных уровнях системы.

Answer 2

[Slava Rozhnev]

У каждого из подходов есть свои преимущества и недостатки.
К недостаткам можно отнести:

• Сложность отладки и тестирования
  
• Затрудненная версионность
  
• Зависимость от конкретной СУБД
  
• Ограниченные возможности языка
  
• Сложности с масштабированием
  
• Возможные side-эффекты
  

К преимуществам:

• Уменьшение трафика
  
• Цетрализованная логика
  
• Безопасность данных
  

Comments

[alexeyshkolnik]

Пока не понятно. Всё минусы какие-то мутные (кроме зависимости от конкретной БД) - их можно натворить в обоих подходах, а плюсы наоборот всё чёткие.

[ksnk]

alexeyshkolnik, Традиционное ООП стороение приложения выделяет слой отображения и слой данных. Бизнес-логика в SQL - означает, что слой данных будет разделен между двумя отдельными системами программирования. Требуется довольно серьезное планирование архитектуры, чтобы угадать какие конкретно компоненты логики не будут менятся в течении жизни приложения.
Единственный разумный минус - дороговизна поддержки. Если для "все в PHP" достаточно квалифицированного кодера, для "неизвестная часть логики в SQL" требуется еще и SQL кодер дополнительно, что может сильно удорожить поддержку.

[alexeyshkolnik]

ksnk, минуточку. здесь еще один набор штампов (я как раз пытаюсь разобраться с одним из них). насколько я понимаю ООП никаких слоев не выделяет он предлагает инструменты абстрагирования, которым хочешь пользуйся, хочешь нет,. Более глубокое расслоение это уже архитектурные паттерны (имхо) - чистая архитектура, хексоганальная архитектура и т.д..
Я не думал о варианте размазывания бизнес-логики между бекендом и БД (пока рассматриваю вариант или там или там).
Про кодера - это тоже спорно - любой приличный кодер бэкенда, как правило неплохо ориентируется и в sql ( предлагаю это оставить за рамками данного топика).

Речь идет о категоричности суждений - я часто читаю о том, что БЛ вообще нельзя помещать в SQL - пытаюсь понять откуда растут ноги - есть же какая то причина такой категоричности. Вот пример: https://habr.com/ru/companies/oleg-bunin/articles/...

[Ипатьев]

alexeyshkolnik, в этой статье Бд рассматривается как хранилище. И все утверждения делаются при этом допущении. Там вообще никак не затрагивается вопрос "можно ли запихать БЛ в БД".

[alexeyshkolnik]

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

[Slava Rozhnev]

alexeyshkolnik, немного поясню:

• дебажить код хранимых процедур гораздо сложнее чем код приложения
  
• гит тоже не особо прикрутишь, что бы версиями управлять. Конечно есть миграции но это не совсем то. Невозможно паралельно запустить несколько версий
  
• С масштабированием тоже проблемы - поднять дополнительный инстанс приложения намного проще чем базу данных да ещё и репликацию
  

[ThunderCat]

Slava Rozhnev, Человек считает себя неким Колумбом и Д'Aртаньяном в одном лице, типа "Вы все тут втираете мне какую-то дичь, о голоде в дороге, цинге и бунтах матросов, это все фигня, я вот доплыву до Индии, тогда и поговорим"... Нюансы разработки его не интересуют, в некоторой степени интересуют технические нюансы, в коих он считает и есть залог успеха проекта.
Характер вредный, не женат... ))

[alexeyshkolnik]

ThunderCat, Колумб, между прочего, все-таки открыл Америку
Если серьёзно, я просто пытаюсь скорректировать направление дискуссии, в интересующую меня сторону.
Не нужно делать необоснованных выводов. А вот за ещё пару юскейсов из жизни, скажу спасибо, как уже сказал за первый.

[ThunderCat]

alexeyshkolnik,

Колумб, между прочего, все-таки открыл Америку

Хотя плыл в Индию... Я как раз это имел в виду ))

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

Так я уже спрашивал - в чем затык? Технически препятствий нет, архитектура нестандартная, но кого и когда это останавливало, если есть желание попробовать острых ощущений? ) Как я уже писал - единственный ваш обозначенный плюс -

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

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

Answer 3

[ThunderCat]

Когда в руках молоток, все вокруг становится похожим на гвоздь... Если вы хорошо разбираетесь в языках запросов, это не говорит о том что это распространенный навык.
Самый простой аргумент - посмотрите на рынок, много ли движков, построенных на бд/sql?
Много ли специалистов по бд вообще на рынке труда?
Кто из них разрабатывал логику на стороне бд?
Кроме того, слои яп-бд можно разнести на разные инстансы, что сильно распределит нагрузку, а бд сама по себе умеет в пожрать ресурсы...

Можно долго перечислять плюсы и минусы. Смысл в том что если вы будете разрабатывать это сами или для себя и вы уверены в собственной способности построить всю логику на одной технологии- флаг в руки, это будет оригинальным решением, вполне возможно даже что найдутся ценители.
Если же проект для заказчика, и в разработке будут участвовать 2+ людей, то тут то вы хапнете проблем большой ложкой. Найти спецов которые прям пишут логику на скуеле, чтобы они стоили приемлемых денег, завтра не ушли в другой проект так как тут надо делать кучу непрофильных дел: как-то делить задачи, вести версионирование, не пересекаться с другими задачами функционалом... проще пойти в нормальную контору, где от дбшника требуют только структуру, пару триггеров и он там один отвечает за бд, так как больше не нужно и ни с кем из коллег не надо 10 раз утверждать изменения в структуре/процедурах/етц. Короче это не специфично и мало кто захочет все это изучать с новой стороны. Про поддержку такого чуда я вообще молчу.

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

Comments

[alexeyshkolnik]

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

[ThunderCat]

alexeyshkolnik,

Всё ваши минусы сводятся конкретно, к сложности поддержки, в связи с отсутствием/дороговизной специалистов?

Это одна из многих проблем. Не по тому что "все привыкли по другому", а по тому что сейчас делают иначе практически все, и если бы с текущей архитектурой наблюдались бы серьезные проблемы, уже выкатили бы стопитьсот фреймворков для разработки БЛ в БД. А их нет, вообще. Значит и всего что сегодня делает разработку удобной, быстрой и недорой (инструменты, специалисты нужной квалификации, тестирование, версионирование, разбиение на объекты и еще миллион мелочей) у вас не будет. Если ваш заказчик хочет - дерзайте, но сразу примите как факт - гемора будет много.

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

Архитектура будет стремной и непривычной, однозначно. Языки бд обычно не содержат абстракций, и бОльшая часть вашего кода будет махровой процедурщиной. Еще раз: если для себя - ок и норм, если для клиента - не срите себе в карму, икать, при упоминании вас добрым тихим словом, будете часто.

Плюсы: очень просто вносить изменения - затрагивается только один слой - база данных, и минимальные или вообще никаких изменений на фронте.

Заменяем слова "база данных" на "бэкенд ЯП" и (о чудо!) ничего не меняется!

[Roman K]

ThunderCat,

Архитектура будет стремной и непривычной, однозначно

Как профессионально и с доказательствами:)

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

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

Не подумай, я не топлю за логику в БД, но аргументы звучат не более чем смехотворно

[ThunderCat]

Roman K,

Как профессионально и с доказательствами:)

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

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

Фишка в том что все эти "тонны" абстракций уже есть, написаны и работают, вам надо только создать экземпляр конкретного класса, настроить связи и ВСЕ! Ничего из так пугающего вас "лишнего" кода никогда даже не загрузится. Для разработчика весь код будет "плотным", так как так нелюбимые вами абстракции над абстракциями уже дают вам на 90% готовый код, вы пишете именно ЛОГИКУ, которой на самом деле не так много.

Answer 4

[Ипатьев]

Вопрос из серии "У меня есть своя дурацкая точка зрения, которую я ни сформулировать толком не могу, ни подкрепить никакими доводами. Давайте, переубеждайте меня!"

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

Но могу вас утешить. Всё это говорится про более-менее сложные приложения.
Говнокодить свою домашнюю страничку про котиков, или интернет магазин по продаже мёда с пасеки любимого дядюшки вы можете как угодно, хоть в SQL, хоть в Brainfuck-e.

Comments

[Roman K]

Категоричность надо оставить на совести ваших собственных нетривиальных интерпретаций

тупо потому что это неудобно

этого велосипеда

ну ясно понятно, копетан некатегоричная объективность

[alexeyshkolnik]

Примеры прикольные, гипреболизированые, но не имеющие отношения к предмету обсуждения. Как аргумент это сложно принять.
Типа: почему рыба плавает в воде? - ха! Ты хоть раз видел, чтобы орёл бегал по лесу? Вот то то и оно.

[Ипатьев]

alexeyshkolnik, я поменял ответ

[Северное Сияние]

бизнес-логика не должна завязываться на конкретное хранилище

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

[Roman K]

Северное Сияние, знаем мы таких теоретиков, которые пришли к практике с попытках абстрагироваться от БД. я прямо сейчас оптимизирую запросы таких "абстрагировальщиков", которые в ORM нахуевертили, где 300 SQL запросов подряд на один http запрос — ещё ничего и жить можно

Answer 5

[Северное Сияние]

Аргумент о том, что будем менять БД не подходит, БД менять ближайшие 10 лет не собираемся

этот аргумент кочует лет 20, причем не только в отношении БД, а вообще всего.

В PHP, например, абстракция PDO - почти такой же надуманный предлог, мол, а если база поменяется?

Вот когда поменяется база, наймут новых разработчиков и они будут заново пилить и переписывать. Потому, что ПО ФАКТУ со сменой базы меняется всё - начиная с формата получения данных в клиентском коде и заканчивая теми участками, где используются какие-то фитчи конкретной СУБД, как, например, в MySql ONLY_FULL_GROUP_BY без которого SQL на другой базе попросту не сработает или функции, специфичные для бывшей/текущей БД.

И что там будет через 10 лет не известно, проект либо раньше загнётся, либо его перепишут с нуля. В ином случае, если проект будет большой, никто его не будет переписывать через внедрение другой СУБД, никогда такого маразма не видел, это всё равно, что менять фундамент у здания - легче новое построить с учётом новых требований.

Между тем, адепты не писать логику в БД почему-то тихо "игнорируют" такие вещи, как внешние ключи и такие вещи как ON DELETE CASCADE с удовольствием используют, а не пишут цикл перебора с методом delete для каждой из связанных сущностей.

Comments

[ThunderCat]

Между тем, адепты не писать логику в БД почему-то тихо "игнорируют" такие вещи, как внешние ключи и такие вещи как ON DELETE CASCADE с удовольствием используют, а не пишут цикл перебора с методом delete для каждой из связанных сущностей.

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

[Roman K]

ThunderCat,

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

То, что эта логика написана руками, всего лишь следствие того, что в этом инструменте просто нет нужных механизмов и их приходится писать руками. Если пофантазировать и представить, что каскадного удаления или блокировок в БД бы не было, то можно легко дойти до того, что их придётся писать руками. Чем этот кейс отличается?

[ThunderCat]

Roman K,

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

Не приходится, их пишут в приложении и формируют запросы в бд согласно требуемым данным для БЛ. По вашей же логике в бд не хватает фреймворка на все случаи жизни, а-ля рубирельсы или ларавель. Вопрос - а почему же его нет, если он так нужен? Ответ, думаю, очевиден...

Если пофантазировать и представить, что каскадного удаления или блокировок в БД бы не было, то можно легко дойти до того, что их придётся писать руками. Чем этот кейс отличается?

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

Answer 6

[FernandoErrNando]

Вам указывали недостатки, но, почему-то для вас "Всё минусы какие-то мутные (кроме зависимости от конкретной БД)".
Давайте попробуем посмотреть повнимательнее:
1. Сложность отладки и тестирования - в то время, когда я работал с такими приложениями была проблема с тем, что средства отладки были слишком неразвиты, зачастую приходилось пользоваться dbms_output и все, чтобы отладить процедуру. думаю, нормыльные даббагеры потом появились, но я уже к тому времени ушел. Как сейчас обстоит с этим в РСУБД?
2. Затрудненная версионность - а разве не так? На больших проектах со множеством разработчиков это ещё как будет стрелять. Просто посмотрите как мучаются люди с данной проблемой https://habr.com/ru/articles/330662/, тогда как те, кто использует БЛ вне базы просто пользуются гитом
3. Зависимость от конкретной СУБД. Вы уверены, что БД у вас всегда будет подходить под требования бизнеса на 10 лет? Что, если за 10 лет появятся задачи, которые лучше решать другими инструментами? А если появятся задачи которые можно решить только сторонними инструментами?
4. "Ограниченные возможности языка" - можно ли решить все проблемы с помощь SQL/PL-SQL?
5. Сложности с масштабированием/оптимизацией - здесь тоже намного сложнее все. Кэширование вы тоже на СУБД будете возлагать? Что будет, когда у вас серверов БД будет больше 1?
6. Что насчет интеграций? Что будет, если вам надо будет ходить по АПИ в третьесторонний сервис? вы это тоже заложите в логику в БД?

Comments

[alexeyshkolnik]

Мутные они на мой взгляд в том, что эти минусы можно легко получить и в приложении, где условна вся БЛ отделена от сервера БД. Разве не так?
По вашим доводам
1. Не готов ответить, здесь много вариантов и отладки и способов строить тестовые среды
2. Посмотрю это интересно. Но замечу затрудненность это же не невозможность.
3. Ага, уверен (пусть будет так для простоты)
4. Думаю почти всё решаемо. В pg вроде даже на c++ можно писать
5. Кэширование это проблема - согласен, pg кстати неплохо с ней справляется. Но это же не совсем БЛ.
Если серверов будет больше 1, то буду работать с несколькими серверами (их кстати сейчас больше одного) - в чем здесь вопрос?
6. Ага - это тоже интересно, естественно придётся задействовать бэкенд, для получения сервисных данных. И думаю не стоит их для обработки отправлять серверу БД. Но есть понимание, что таких запросов будет, где-то 2% (возможно здесь я не прав)

P. S. Если можно, попрошу обойтись без пассивной агрессии.

[FernandoErrNando]

Уж никак не думал, что меня объявят пассивно-агрессивным, однако, извиняюсь, если это так звучит. Скорее, я пытался дать альтернативный взгляд на проблему, потому что вопрос интересный.

1. -
2. А какой параметр мы пытаемся оптимизировать? Обычно ставят в основу быстроту разработки, которая состоит в легкости поддержки и внесения изменений в код, соответственно, зачем преодолевать трудности именно в этом?
3. Мой опыт полностью противоположен, я уверен, что за 10 лет поменяется полностью архитектура проекта и не один раз как раз из-за изменения требований. естественно, это будет происходить не одномоментно. Впрочем, против уверенности мне возразить нечего.
4. А бизнес-логика разве в таком случае не будет распределена уже на 2 слоя: БД и модуль на с++, который надо ещё как-то скомпилировать?
5. Ну в целом, для кэширования просто можно было бы использовать стороннее хранилище, например, Redis, что увеличило бы скорость работы системы, а также снизило бы загрузку основной БД. Что касается множества инстансов БД, то возникают вопросы реплицирования и партиционирования данных и БЛ, которые тоже, возможно, могли бы быть решены гораздо проще.
6. Если у вас именно такой проект - вполне можно.

Поймите, все зависит от требований и насколько быстро надо менять бизнес-логику. Есть до сих пор системы в эксплуатации, которые написаны на BASIC, Cobol, Delphi или ещё на чем-нибудь древним и их пока не переводят по целому ряду причин.

З.Ы. В целом, сложилось впечатление, что у вас есть какой-то определенный специфичный случай, который вы не описываете, но пытаетесь решить. Я рекоммендую не закцикливаться на выбранном варианте, а рассматривать больше альтернатив. В конце концов, никто не спорит, что молоток - хороший инструмент, но применять его везде не всегда оправдано.

[alexeyshkolnik]

FernandoErrNando,
Кейс достаточно простой/распространенный обычная распределённая бизнес система с очень большим количеством товаров/продавцов/покупателей и требованием заказчика в реализации бл в sql и выбора субд. Я исследую вопрос в контексте контраргументов, и пока не нашёл, чего то конкретного, чтоб можно было сказать -
"смотри если так сделаем, то нам капец, по таким то причинам". Всё говорит о том, что нам может быть когда-то капец, а может и нет.
Хороший вариант с зоопарком сервисов получения данных (микросервисы, шины, эластик, БД), но этого пока мало, хотя сейчас в проекте только эластика нет.
С редисом не всё однозначно, есть подозрения, что pg сам себя кэширует лучше.
По поводу бизнес требований согласен - поменяются 100 раз. Но как говорил король в "Убить дракона": " не сейчас, не сегодня и не бизнес требования"

Короче самые лучшие коменты для меня это конкретные юскейсы: типа смотри мы вот сделали и огребли такие-то проблемы, потом переделали вот так и эти проблемы ушли, но появились новые такие-то.

Понимаю, что получу то, что хочу не в одном коменте, а в диалоге, поэтому ценю каждый отклик.

[ThunderCat]

alexeyshkolnik,

и требованием заказчика в реализации бл в sql и выбора субд.

Если речь идет про осознанный выбор кактуса вместо пшена, то о чем вообще речь? Чисто физически БЛ пишется хоть в экселе. То есть физических преград нет, есть вопросы удобства и скорости разработки, поддержки и прочих нужных вещей, если на них забить изходя из принципа "хочу так", то задача выполнимая, хотя и в разы более сложная, нежели создание всего того же, но средствами ЯП.

Вообще не понятно откуда такое желание возникло? Что не устроило в современной схеме распределения ответственностей между ЯП и БД?

[alexeyshkolnik]

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

[FernandoErrNando]

TLDR: Был опыт, столкнулся со след проблемами:

• проблема с кадрами,
  
• проблема с отладкой,
  
• проблема с версионированнием
  

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

При этом миграции структуры таблиц были через стандартные средства фреймворка, а миграции хранимок - через SQL-файлы в гите, которые подгружались через специальную консольную команду. Проблем было несколько:
1. Хранимки хорошо знал один из тимлидов (который, собственно и написал их), однако в команде в целом не сильно знали как писать их правильно, прихоидлось много рыскать по мануалам или спрашивать у него лично. Лично меня спасало то, что когда-то я на Оракле с этим работал в студенчестве, что-то помнил из тех времен.
2. Для разработки мы использовали докер, в котором крутился Postgres, но для дев-образа не был установлен модуль для деббагинга, что выливалось в необходимость отладки методом внимательно разглядывания кода или аналогом dbms_output / выбросом исключений. Я пробовал сам его прикрутить, однако тогда не настолько знал докер, поэтому потерпел неудачу и оставил это занятие, благо задач на хранимки было не так много.
3. Ещё одна проблема была в том, что в проекте использовался ребейз. Код мерджить мог только тимлид, однако ввиду занятости он иногда делал это ночью, когда его никто не отвлекал с запросами. Поскольку он мерджил по неск. МР-ов за раз, то можно было неправильно померджить с потерей информации. У моего напарника был случай, когда в одну из таких ночей тимлид неправильно померджил одну из хранимок которую переписал коллега, в результате процедура отрабатывала нормально кроме некоторых кейсов. Поскольку баг выпал как раз на коллегу и он смог заметить, что код хранимки какой-то странный, сравнив файл с текстом со своей локальной веткой, то он смог найти причину достаточно быстро. Что было бы, если версионировалось все в бд - хз, думаю, проблем было бы больше.

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

[ThunderCat]

alexeyshkolnik,

главная причина - это дурацкая привычка задавать вопросы (и у меня и у заказчика).

Вопросы всегда надо задавать парами. Например - можно ли так делать?, и в пару - а почему так не делают примерно никто? Ну или "а что мы выигрываем при таком подходе?".

соврменная это же не значит автоматически, правильная или лучшая.

Согласен. Готовы стать пионером в изобретении новой меты? Много крови, пота, гемора и потраченных денег, зато в итоге - лавры победителя (или нет). Вопрос не в невозможности, это тупо не выгодно на сегодняшнем этапе развития технологий.

[ThunderCat]

alexeyshkolnik,

Я исследую вопрос в контексте контраргументов, и пока не нашёл, чего то конкретного, чтоб можно было сказать - "смотри если так сделаем, то нам капец, по таким то причинам". Всё говорит о том, что нам может быть когда-то капец, а может и нет.

Стабильность и предсказуемость - наше всё ))

Хороший вариант с зоопарком сервисов получения данных (микросервисы, шины, эластик, БД), но этого пока мало, хотя сейчас в проекте только эластика нет.

Мало для чего, в чем затык?

С редисом не всё однозначно, есть подозрения, что pg сам себя кэширует лучше.

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

Короче самые лучшие коменты для меня это конкретные юскейсы: типа смотри мы вот сделали и огребли такие-то проблемы, потом переделали вот так и эти проблемы ушли, но появились новые такие-то.

В 2005 мы писали что-то типа внебрачного сына ютуба и фейсбука. Наш ДБА во первых уговорил нас на SQL Server, а во вторых, в творческом порыве понастругал хранимок, в которых, надо сказать, очень неплохо разбирался (и разбирается). Так вот, скрестить линукс с SQL S на тот момент не удалось, а сервер от мс с нужным софтом стоил просто запредельных денег. Пока все было на бесплатной тестовой версии можно было терпеть некоторые косяки (по типу своей версии UTF кодировок, типа UCS, не совпадающей в 10 символах с UTF-8 например), вытекающие из такого зоопарка, но когда посчитали что за софт будет выходить сумма сопоставимая с покупкой еще 2 серверов, быстро переползли на мускуль, похерили все хранимки, так как ДБА уже было лень все переносить руками, и написали нормальную логику. В итоге ДБА ушел с проекта чуть позже, так что в любом случае хранимками заниматься было бы некому, нам просто повезло что это произошло само собой, а не внезапно по уходу спеца. Вот такой кейс был...

[alexeyshkolnik]

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

[alexeyshkolnik]

ThunderCat, а забыл. Стабильность - очень так себе аргумент. Можно ещё сказать зачем ты раскачиваешь лодку . Антихрупкость уж тогда. Но это всё оффтоп.

[ThunderCat]

alexeyshkolnik,

Всем нравоучениям улыбаюсь но не более.

А при чем тут нравоучения? Есть, скажем так, здравый смысл, опыт и боль рефакторинга кучи проектов, спроектированных как раз по такому принципу "инновационного подхода", ничего кроме как попробовать отговорить вас от решений, принесущих кучу проблем и мизер профита вам здесь не писали. Ничего из того что можно было бы назвать "нравоучением", вам здесь не написали. Хотите делать по своему - да пожалуйста. Были ли попытки сделать что-то похожее? Да, были. Было ли это профитным - в известных мне случаях однозначно нет. Спор о логике в бд и тут уже несколько раз затрагивался, пока никто ничего толкового на этой идее не построил. По этому советы большинства присутствующих - не беритесь. Чисто из соображений гуманизма.

[ThunderCat]

alexeyshkolnik,

Стабильность - очень так себе аргумент.

Ага, владельцу бизнеса это скажите ) Это же не политика, в разработке важно знать что ты получишь на выходе, собственно куча фреймворков это как раз попытка максимально стабилизировать разработку. Если у вас цель - творческий эксперимент, а не продукт, то подход интересный, в ином случае я бы придерживался более классического подхода.

[alexeyshkolnik]

ThunderCat, про нравоучения поподробнее, раз уж зашла речь.
"Здравый смысл" - всего лишь словесная коснтрукция, целью которой несомненно является манипуляция.
Аргументация про карму, или вида "неделай так, потому что так умный дядя говорит", "из соображений гуманизма" и прочее - в нормальном мире не работает, по простой причине, это все тоже не аргументы, а манипулятивные техники, причем очень примитивные.
Естественно в манипуляции нет ничего плохого и иногда она полезна (чаще на коротких дистанциях и чтоб затукнуть условные "дырки") но чаще вредит и автору и потребителю.
Рекомендую ей пользоваться осознано и не злоупотреблять.
Я в этом топике в любом случае увижу все полезные аргументы, для этого и завел.

[alexeyshkolnik]

ThunderCat, коенчно скажу - в бизнесе как и в жизни выживает не стабильный (сильнейший), а тот кто лучше приспасабливается (гибкий), адаптируется к изменениям. Можно конечно сформулировать как "стабильно гибкий" - но это уже словоблудие, типа "отрицательного роста" и т.д. и т.п.

[ThunderCat]

alexeyshkolnik,

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

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

Отдельно про "здравый смысл". Да, это как и вся наша речь - словесная конструкция. И да, мы манипулируем людьми через слова. В контексте вышеописанного - выдранное из фразы "здравый смысл" подразумевал все объективные причины, которые я перечислил выше в коментариях, есть смысл их повторять?

Аргументация про карму, или вида "неделай так, потому что так умный дядя говорит"

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

Кстати, не постыдитесь постесняйтесь написать хоть потом, что получилось то...

[alexeyshkolnik]

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

[alexeyshkolnik]

ThunderCat, ага - через пару дней, попробую сформулировать предварительные итоги

[Дмитрий Кинаш]

alexeyshkolnik,

Я исследую вопрос в контексте контраргументов, и пока не нашёл, чего то конкретного, чтоб можно было сказать -
"смотри если так сделаем, то нам капец, по таким то причинам". Всё говорит о том, что нам может быть когда-то капец, а может и нет.

Тогда правильного ответа для тебя не будет. Если руки "золотые", то получится сделать все мега-эффективно. Если руки "из жопы", то следование патернам и всем бестпрактикам мира не помогут.

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