Коллеги,
Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах? Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы? Учитывая, что код на sql как правило более локаничный и лучше читается.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах? Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы? Учитывая, что код на sql как правило более локаничный и лучше читается.
Про фэн-шуй не будем, это и без меня расскажут. С практической точки зрения — ну можно, да. При наличии определённых условий, разумеется.
1. Проект долгоживущий, сознательно завязан на определённую РСУБД и не планирует мигрировать в облако "как-нибудь потом". Если тут объяснения нужны — дополню.
2. Скрипты хранятся вместе с прочими исходниками (отдельным проектом, разумеется) и проверяются по тем же принципам — тесты, билд-сервер, скрипты миграции с обязательной проверкой деплоем на предыдущие выпущенные версии и тыды и тыпы.
3. В скриптах лежит только то, что туда действительно имеет смысл выносить. Тупо перегонять всю БЛ на сторону СУБД неэффективно во всех смыслах, что по поддержке, что по производительности.
Ну а что именно паковать в скрипты — родной sql, хранимки или view — эт уже на усмотрение разработчиков.
Здравствуйте, Sinix, Вы писали: S>Про фэн-шуй не будем, это и без меня расскажут. С практической точки зрения — ну можно, да. При наличии определённых условий, разумеется.
Я бы про ОРМ высказался "ну можно, да..." Когда вы проверили генерируемый запрос, что этой ОРМ и этой версией ОРМ он более ни менее нормально генерируется. И если не так критично вытаскивание из базы избыточного объема данных чтобы заполнить поля сущности, которые не используются.
А в целом от ОРМ гораздо больше проблем, чем выгоды.
G>Я бы про ОРМ высказался "ну можно, да..." Когда вы проверили генерируемый запрос, что этой ОРМ и этой версией ОРМ он более ни менее нормально генерируется. И если не так критично вытаскивание из базы избыточного объема данных чтобы заполнить поля сущности, которые не используются.
кто мешает вытащить только те данные, которые нужно и не тащить лишних?
G>А в целом от ОРМ гораздо больше проблем, чем выгоды.
G>Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах?
вопрос изначально поставлен так, что вы уже для себя ришили что лучше. пришли найти поддержку своего решения?
G>Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы?
ужасный SQL код они генерируют когда человек, который пишет запрос с использованием ORM, не понимает что он делает.
но тот же результат будет если этот же человек начнет писать sql запрос.
G>Учитывая, что код на sql как правило более локаничный и лучше читается.
только что касается выборки реляционных данных.
в остальном мы получаем кучу проблем.
— реализовывать сложную логику в разы сложнее и код становится страшным
— сложности с переиспользованием кода. либо просядет по перфомансу, либо копипастить
— плохая тестируемость
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:
G>>Я бы про ОРМ высказался "ну можно, да..." Когда вы проверили генерируемый запрос, что этой ОРМ и этой версией ОРМ он более ни менее нормально генерируется. И если не так критично вытаскивание из базы избыточного объема данных чтобы заполнить поля сущности, которые не используются.
HBM>кто мешает вытащить только те данные, которые нужно и не тащить лишних?
ОРМ мешает. У меня, допустим замеплина таблица на сущность, а из этой сущности нужно пару столбцов для отчета. ОРМ всю сущность вытащит и дальше вы будете работать с теми полями что вам нужно.
G>>А в целом от ОРМ гораздо больше проблем, чем выгоды. HBM>может быть вы просто не умеете его готовить?
Вот затраты на эту готовку слишком большие. Вы должны написать запрос с помощью ORM, потом посмотреть во что оно мапится, потом переписать, потом увидеть что не помогло и т.д. Вместо того, чтобы сразу написать нормальный SQL запрос. И как раз таки я заметил что среди сторонников ORM много тех, кто не умеет готовить SQL как раз таки
HBM>>кто мешает вытащить только те данные, которые нужно и не тащить лишних? G>ОРМ мешает. У меня, допустим замеплина таблица на сущность, а из этой сущности нужно пару столбцов для отчета. ОРМ всю сущность вытащит и дальше вы будете работать с теми полями что вам нужно.
кто мешает создать еще одну DTO с теми полями, которые нужны и не тянуть все?
G>>>А в целом от ОРМ гораздо больше проблем, чем выгоды. HBM>>может быть вы просто не умеете его готовить? G>Вот затраты на эту готовку слишком большие. Вы должны написать запрос с помощью ORM, потом посмотреть во что оно мапится, потом переписать, потом увидеть что не помогло и т.д. Вместо того, чтобы сразу написать нормальный SQL запрос. И как раз таки я заметил что среди сторонников ORM много тех, кто не умеет готовить SQL как раз таки
ну конечно. 100500 CRUD хранимых это прям рай.
на каждый чих по хранимой. на каждую мелкую сущность по 5 хранимых.
не не не девид блейн
оптимизировать sql нужно тогда, когда есть проблемы с перфомансом. 90% операций приложения это таки CRUD, а с ним любая ORM отлично справляется.
а дальше при необходимости в некоторых местах можно и хранимыи использовать, если будет нужно.
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:
G>>Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах? HBM>вопрос изначально поставлен так, что вы уже для себя ришили что лучше. пришли найти поддержку своего решения?
А вы заметили, в наблюдательности вам не откажешь... Это мотивация была.
G>>Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы?
HBM>ужасный SQL код они генерируют когда человек, который пишет запрос с использованием ORM, не понимает что он делает. HBM>но тот же результат будет если этот же человек начнет писать sql запрос.
Ну это подмена понятий. Давайте исходить из того, что человек и sql нормально пишет и ORM хорошо знает.
G>>Учитывая, что код на sql как правило более локаничный и лучше читается.
HBM>только что касается выборки реляционных данных. HBM>в остальном мы получаем кучу проблем. HBM>- реализовывать сложную логику в разы сложнее и код становится страшным
Сказки про страшный код. А что такое красивый код? По мне так это высокопроизводительный код. HBM>- сложности с переиспользованием кода. либо просядет по перфомансу, либо копипастить
Не понятен аргумент. HBM>- плохая тестируемость
Отличная тестируемость, просто тестируйте сквозные сценарии и все будет ОК.
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:
HBM>кто мешает создать еще одну DTO с теми полями, которые нужны и не тянуть все?
DTO? Опа... Ну ладно, потому что этих DTO ваших станет немерено просто — рост логарифмический буквально.
G>>>>А в целом от ОРМ гораздо больше проблем, чем выгоды. HBM>>>может быть вы просто не умеете его готовить? G>>Вот затраты на эту готовку слишком большие. Вы должны написать запрос с помощью ORM, потом посмотреть во что оно мапится, потом переписать, потом увидеть что не помогло и т.д. Вместо того, чтобы сразу написать нормальный SQL запрос. И как раз таки я заметил что среди сторонников ORM много тех, кто не умеет готовить SQL как раз таки
HBM>ну конечно. 100500 CRUD хранимых это прям рай. HBM>на каждый чих по хранимой. на каждую мелкую сущность по 5 хранимых. HBM>не не не девид блейн
Но вот тут как раз таки можно ОРМ применять, как я написал выше. Это единственное с чем оно может справлятся.
HBM>оптимизировать sql нужно тогда, когда есть проблемы с перфомансом. 90% операций приложения это таки CRUD, а с ним любая ORM отлично справляется.
Ерунда. Нужно сразу писать оптимальный код. Преждевременная пессимизация приводит к проектам, которые и за полгода не отрефакторишь. HBM>а дальше при необходимости в некоторых местах можно и хранимыи использовать, если будет нужно.
G>Я бы про ОРМ высказался "ну можно, да..."
Тут от языка / фреймворков / требований проекта / СУБД в бэкенде зависит.
Если язык не умеет в linq, фреймворк (подставить косяк по вкусу), проект позволяет тратить время на сопровождение скриптов при каждом рефакторинге, а оптимизатор СУБД захлёбывается на простейших запросах (не будем говорить кто, но постгре в этом смысле ещё ничего), то да — наличие / отсутствие ORM меньшая из проблем.
G>А в целом от ОРМ гораздо больше проблем, чем выгоды.
Ну блин. ORM не сами по себе работает, он должен в стеке использоваться. Т.е. плюс локальные транзакции, плюс change tracking плюс сериализация изменений по сети, + обработка в одной транзакции данных, которые объявлены в разных сборках (т.е. общего репо как такового, нет) + умный коммит + автомиграция / авторазвёртывание и тыды и тыпы.
Это как бумажные чертежи vs проектирование в цифре — основной выигрыш получается, когда используется вся цепочка, вплоть до инструментального контроля. Иначе получается "дядя Вася с киянкой цифру не понимает — отстой ваша цифра".
HBM>только что касается выборки реляционных данных. HBM>в остальном мы получаем кучу проблем.
Не совсем с той стороны проблемы описываете. Всё это решается, только за совсем отдельные деньги. Во-первых, девелопер должен _знать_ выбранную РСУБД. Не уметь писать select*from, а именно знать. Как отдельный язык программирования.
Во-вторых, sql не прощает ошибок из-за поголовной убогости инструментальных средств. Рефакторинг, глобальная проверка скриптов, поменять схему данных без приседаний? Не, не слышал. Т.е. разработчик должен быть ещё и опытным и уметь думать _до_ того, как делать (что после уютной студии немножко так напрягает).
Ну и в третьих, разработчик должен хоть немножко уметь в архитектуру и в предметную область. См предыдущий пункт, поздно всплывший косяк в дизайне схемы может не чиниться годами, ибо его исправление стоит на пару порядков дороже, чем час работы горячей линии, которая про этот косяк уже знает и умеет чинить где-то раз в год.
Ну и где вы таких добровольцев нынче найдёте в товарных количествах? И, главное, замотивируете тратить время на нудятину поддержки вместо более полезных вещей?
Поэтому лучше использовать "голый" sql там, где от него баланс польза/страдания положительный и закопать его подальше во всех остальных местах.
G>>>Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах? HBM>>вопрос изначально поставлен так, что вы уже для себя ришили что лучше. пришли найти поддержку своего решения? G>А вы заметили, в наблюдательности вам не откажешь... Это мотивация была.
это аргумент в сторону того, что вести на эту тему дискуссию изначально не имеет смысла, так как вы твёрдо уверены в своей правоте и будете предвзяты
HBM>>только что касается выборки реляционных данных. HBM>>в остальном мы получаем кучу проблем. HBM>>- реализовывать сложную логику в разы сложнее и код становится страшным G>Сказки про страшный код. А что такое красивый код? По мне так это высокопроизводительный код.
красивый код понятие конечно относительно.
я вкладываю в это часто лаконичность.
если я могу при помощи F# решить задачу 3мя строками, а на SQL — 25 строк, то выбор для меня очевиден
HBM>>- сложности с переиспользованием кода. либо просядет по перфомансу, либо копипастить G>Не понятен аргумент.
что тут непонятного? переиспользовать имеющийся код в SQL крайне сложно. модульности нет.
HBM>>- плохая тестируемость G>Отличная тестируемость, просто тестируйте сквозные сценарии и все будет ОК.
HBM>>кто мешает создать еще одну DTO с теми полями, которые нужны и не тянуть все? G>DTO? Опа... Ну ладно, потому что этих DTO ваших станет немерено просто — рост логарифмический буквально.
их станет столько, сколько необходимо. плохого ничего в этом нет.
HBM>>ну конечно. 100500 CRUD хранимых это прям рай. HBM>>на каждый чих по хранимой. на каждую мелкую сущность по 5 хранимых. HBM>>не не не девид блейн G>Но вот тут как раз таки можно ОРМ применять, как я написал выше. Это единственное с чем оно может справлятся.
ну хоть на этом сошлись. уже отлично
HBM>>оптимизировать sql нужно тогда, когда есть проблемы с перфомансом. 90% операций приложения это таки CRUD, а с ним любая ORM отлично справляется. G>Ерунда. Нужно сразу писать оптимальный код. Преждевременная пессимизация приводит к проектам, которые и за полгода не отрефакторишь.
преждевременная оптимизация не меньшее зло. код должен быть нормальным, но нет смысла гнаться за +1% перфоманса.
HBM>>а дальше при необходимости в некоторых местах можно и хранимыи использовать, если будет нужно.
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали: HBM>красивый код понятие конечно относительно. HBM>я вкладываю в это часто лаконичность. HBM>если я могу при помощи F# решить задачу 3мя строками, а на SQL — 25 строк, то выбор для меня очевиден
Вот только на F# у вас не 3 строчки получится и не 30 и не 300 чтобы получить аналог. Когда начинаешь рассказывать про эскалации блокировок, про уровни изоляции транзакция, про то что СУБД может автоматически выбирать nested loop или merge join или hash join. И что эффективность в зависимости от данных сильно разная. Люди начинают понимать, что это не просто select под капотом куча алгоритмов и что SQL гораздо более высокоуровневый чем они думали. Тогда становится понятным какой примитив эти 3 строчки на F#.
HBM>>>- сложности с переиспользованием кода. либо просядет по перфомансу, либо копипастить G>>Не понятен аргумент.
HBM>что тут непонятного? переиспользовать имеющийся код в SQL крайне сложно. модульности нет.
Вы переоцениваете значимость красивого и удобного кода, как и многие программисты. Компаниям глубоко плевать на то насколько качественный код. Но вот если они потеряют данные или у них будет что-то тормозить — сразу заметят. Неудобный код — решается просто, нанимаем еще одного программиста и все...
Слишком многие программисты гонятся за "красивостью", слишком ее переоценивая.
HBM>писать интеграционные тесты сложнее и накладнее.
Только они будут тестировать то, что происходит на самом деле, а не моки.
HBM>>красивый код понятие конечно относительно. HBM>>я вкладываю в это часто лаконичность. HBM>>если я могу при помощи F# решить задачу 3мя строками, а на SQL — 25 строк, то выбор для меня очевиден G>Вот только на F# у вас не 3 строчки получится и не 30 и не 300 чтобы получить аналог. Когда начинаешь рассказывать про эскалации блокировок, про уровни изоляции транзакция, про то что СУБД может автоматически выбирать nested loop или merge join или hash join. И что эффективность в зависимости от данных сильно разная. Люди начинают понимать, что это не просто select под капотом куча алгоритмов и что SQL гораздо более высокоуровневый чем они думали. Тогда становится понятным какой примитив эти 3 строчки на F#.
есть задачи, где этот метод решения будет лучшим.
есть задачи, когда проще поднять какой-нить кластер из 100 машинок и распараллелить вычисления.
это может быть проще и дешевле, чем искать крутого спеца в сиквеле.
проще говоря, нужно использовать подходящий инструмент в каждом конкретном случае.
а у нас сферический конь в вакууме.
HBM>>что тут непонятного? переиспользовать имеющийся код в SQL крайне сложно. модульности нет. G>Вы переоцениваете значимость красивого и удобного кода, как и многие программисты. Компаниям глубоко плевать на то насколько качественный код. Но вот если они потеряют данные или у них будет что-то тормозить — сразу заметят. Неудобный код — решается просто, нанимаем еще одного программиста и все... G>Слишком многие программисты гонятся за "красивостью", слишком ее переоценивая.
плохой код сложно поддерживать.
когда из-за плохого кода реализация новой фичи начнет занимать не 1 неделю, а месяц, бизнесс это заметит куда быстрее, из-за возврастающих дополнительных расходов, нежели разницу в отклике rest api между 400мс и 600мс.
HBM>>писать интеграционные тесты сложнее и накладнее. G>Только они будут тестировать то, что происходит на самом деле, а не моки.
а вы не тестируйте моки в юнит-тестах и всё будет хорошо.
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:
HBM>есть задачи, где этот метод решения будет лучшим. HBM>есть задачи, когда проще поднять какой-нить кластер из 100 машинок и распараллелить вычисления.
Таких задач нет. HBM>это может быть проще и дешевле, чем искать крутого спеца в сиквеле.
Часто сторонники таких решений с открытым ртом наблюдают как старенький ноутбук возит ораву из 10 серверов... Главное какие алгоритмы вы используете, а не сколько у вас машин. Которые, кстати, еще и админить надо.
HBM>проще говоря, нужно использовать подходящий инструмент в каждом конкретном случае. HBM>а у нас сферический конь в вакууме.
Ну давайте конкретный пример разберем — предлагайте. Просто сам по себе форум архитектура подразумевает абстрактыне рассуждения.
HBM>>>что тут непонятного? переиспользовать имеющийся код в SQL крайне сложно. модульности нет. G>>Вы переоцениваете значимость красивого и удобного кода, как и многие программисты. Компаниям глубоко плевать на то насколько качественный код. Но вот если они потеряют данные или у них будет что-то тормозить — сразу заметят. Неудобный код — решается просто, нанимаем еще одного программиста и все... G>>Слишком многие программисты гонятся за "красивостью", слишком ее переоценивая.
HBM>плохой код сложно поддерживать. HBM>когда из-за плохого кода реализация новой фичи начнет занимать не 1 неделю, а месяц, бизнесс это заметит куда быстрее, из-за возврастающих дополнительных расходов, нежели разницу в отклике rest api между 400мс и 600мс.
Они попробуют нанять еще несколько программистов. Долго слушать сказки про рефакторинг никто не будет.
HBM>а вы не тестируйте моки в юнит-тестах и всё будет хорошо.
Ну так я и предлагаю делать сквозное тестирование.
HBM>>кто мешает вытащить только те данные, которые нужно и не тащить лишних? G>ОРМ мешает. У меня, допустим замеплина таблица на сущность, а из этой сущности нужно пару столбцов для отчета. ОРМ всю сущность вытащит и дальше вы будете работать с теми полями что вам нужно.
Пара столбцов для отчета — это для ОРМ не сильно проблема. Проблема — когда надо из большой группы сущностей превратить общий отчетный документ. Здесь, конечно, намного проще (лично для меня) составить процедуру, которая бы последовательно формировала нужную выборку. А вот для обычного crud все-таки ОРМ очень удобен. Я бы не бросался в крайности и использовал совместное решение: ОРМ + сложные выборки на sql
Здравствуйте, Vasiliy2, Вы писали:
V>Пара столбцов для отчета — это для ОРМ не сильно проблема. Проблема — когда надо из большой группы сущностей превратить общий отчетный документ. Здесь, конечно, намного проще (лично для меня) составить процедуру, которая бы последовательно формировала нужную выборку. А вот для обычного crud все-таки ОРМ очень удобен. Я бы не бросался в крайности и использовал совместное решение: ОРМ + сложные выборки на sql
Разделяю вашу точку зрения полностью. Вот только она как раз и идет в разрез с мнением, что бизнес логика в хранимках это плохо. Это я про те самые сложные выборки.
HBM>>есть задачи, где этот метод решения будет лучшим. HBM>>есть задачи, когда проще поднять какой-нить кластер из 100 машинок и распараллелить вычисления. G>Таких задач нет.
нет вообще или нет конкретно в вашей компании?
HBM>>это может быть проще и дешевле, чем искать крутого спеца в сиквеле. G>Часто сторонники таких решений с открытым ртом наблюдают как старенький ноутбук возит ораву из 10 серверов... Главное какие алгоритмы вы используете, а не сколько у вас машин. Которые, кстати, еще и админить надо.
машины админить не надо, всё на автомате.
горизонтальное масштабирование всегда дешевле вертикального.
HBM>>проще говоря, нужно использовать подходящий инструмент в каждом конкретном случае. HBM>>а у нас сферический конь в вакууме. G>Ну давайте конкретный пример разберем — предлагайте. Просто сам по себе форум архитектура подразумевает абстрактыне рассуждения.
да у меня нет сейчас таких задач. у меня всё хорошо
HBM>>плохой код сложно поддерживать. HBM>>когда из-за плохого кода реализация новой фичи начнет занимать не 1 неделю, а месяц, бизнесс это заметит куда быстрее, из-за возврастающих дополнительных расходов, нежели разницу в отклике rest api между 400мс и 600мс. G>Они попробуют нанять еще несколько программистов. Долго слушать сказки про рефакторинг никто не будет.
и это приведет в итоге к еще большим проблемам и временным затратам. ведь плохой код, а в частности, технический долг, он как снежный ком.
HBM>>а вы не тестируйте моки в юнит-тестах и всё будет хорошо. G>Ну так я и предлагаю делать сквозное тестирование.
еще раз — это сложно.
когда нужно протестировать простой кейс, вам нужно нагнать кучу связных данных, иначе оно работать не будет.
и каждый тест будет огромным и тяжело поддерживаемым. а значит, что скорее всего их никто писать и поддерживать не будет.
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:
HBM>нет вообще или нет конкретно в вашей компании?
Философского камня нет вообще или конкретно вы его не видели?
HBM>>>это может быть проще и дешевле, чем искать крутого спеца в сиквеле. G>>Часто сторонники таких решений с открытым ртом наблюдают как старенький ноутбук возит ораву из 10 серверов... Главное какие алгоритмы вы используете, а не сколько у вас машин. Которые, кстати, еще и админить надо.
HBM>машины админить не надо, всё на автомате. HBM>горизонтальное масштабирование всегда дешевле вертикального.
Объясняю на пальцах. У одного из компьютеров посыпался диск, у второго винда начала обновление. Что тогда?
