Comments 31
Потом пойти как-нибудь к PHP программисту и сказать, вот тебе 25 таблиц, только отреплицированных в XML, и ты тоже повтори этот алгоритм.
Вот это вот не понял. Повторить алгоритм — джойнить xml, делать селекты из xml и реализовывать бизнес-логику?
Не статья, а сплошной бальзам. Тоже всю жизнь писал бизнес-логику на хранимых процедурах, а это оказывается не модно сейчас. Особенно, конечно про оторванность от интерфейса, убийственный аргумент. Да и FK, constains и триггеры, как всё просто и логично.
Спасибо!
Шикарно. Просто шикарно.
А это не тоже самое будет, что и Application Express от Oracle?
И ни слова про отладку всего этого счастья.
Ну, сложно рассказать что-то особо новое и интересное про отладку в отладчике и нотисами
были слова, там звучало профилирование, но это было про отладку.
хотя… что рассказывать? степ форвард? степ инту? обычная отладка, как у всех, как везде.
хотя… что рассказывать? степ форвард? степ инту? обычная отладка, как у всех, как везде.
4 года работал в банке из топ 250, с самописной системой на хранимках и Oracle. Тоже не понимаю, что там про отладку рассказывать. Скомпилил с дебагом и отлаживай.
Плюс pl/sql реально простой язык, там такого, что по ошибке и по коду программы не можешь понять что происходит, случается гораздо реже чем в других языках. Чаще дастаточно взять select, подставить параметры и дернуть посмотреть что возвращается.
Плюс pl/sql реально простой язык, там такого, что по ошибке и по коду программы не можешь понять что происходит, случается гораздо реже чем в других языках. Чаще дастаточно взять select, подставить параметры и дернуть посмотреть что возвращается.
Не понятно что представляла ваша система, возможно у вас проблем с отладкой не было. Но есть такой «замечательный» продукт как Oracle apex, где с отладкой серьезные проблемы, да и не только с отладкой, этот продукт один сплошной геморой. Он заточен под веб, множество процедур хранится как текст таблицах oracl'a apex. Их не скомпилишь и не отладишься как вы пишите. pl/sql язык сам по себе уродливый, синтаксис как в QBASIC. После нормальных языков все эти if then; end if; end loop; просто выбешивают, особенно если там есть вложенные циклы, просто теряешься в коде.
Система обычный клиент-сервер, с клиентами на Winfoms.
APEX да, не очень удачное решение.
Уродливость — в глазах смотрящего. Я просто помню, все эти холивары еще на RSDN про уродливость скобочек в лиспе. А в итоге, сейчас без слез на популярный javascript с тремя видами закрывающихся скобочек, в меремешку с точкой с запятой, смотреть нельзя.
APEX да, не очень удачное решение.
Уродливость — в глазах смотрящего. Я просто помню, все эти холивары еще на RSDN про уродливость скобочек в лиспе. А в итоге, сейчас без слез на популярный javascript с тремя видами закрывающихся скобочек, в меремешку с точкой с запятой, смотреть нельзя.
Я бы сказал, что pl/sql — очень приятный, простой и понятный язык, который новичок может освоить очень быстро. Для своей области применения он хорош. Так что всё это, как обычно, дело вкуса и привычек.
Спасибо за статью. Согласен с вами во всем.
нет проблем с хранимыми процедурами, есть проблема с кадрами и мировым опытом, на все вопросы по PHP или C# легко найти ответы на Stack Overflow, с pg не так просто.
если проект маленький то наверное не сложно найти 1 программиста на замену ушедшему, а если проект побольше? и надо искать по 10 программистов с такой узкой специализацией на pg?
как бы трёх звенная система подразумевает большую модульность, как бы большую гибкость, можно больше железа выделить или на сервер приложений или на сервер БД, в зависимости от потребностей, а в случаи двух звенки, без вариантов, вы всегда «усиливаете» сервер БД, хотя конечно гибкость сохраняется в том что бы или дисковую подсистему бустить или процессор и память :)
если проект маленький то наверное не сложно найти 1 программиста на замену ушедшему, а если проект побольше? и надо искать по 10 программистов с такой узкой специализацией на pg?
как бы трёх звенная система подразумевает большую модульность, как бы большую гибкость, можно больше железа выделить или на сервер приложений или на сервер БД, в зависимости от потребностей, а в случаи двух звенки, без вариантов, вы всегда «усиливаете» сервер БД, хотя конечно гибкость сохраняется в том что бы или дисковую подсистему бустить или процессор и память :)
Адский ад для разработки в случае, если ей занимается больше одного человека. Нет интеграции с git, и придётся писать какой-то велосипед чтобы иметь версионирование. Нет системы для деплоя. Отладка через одно место.
Мы делали примерно то же самое для системы ЕИАС с сотнями тысяч пользователей, и с тех пор, когда я слышу слово «хранимые процедуры», я хватаюсь за пистолет. Там была ещё масса всякой специфики Oracle в виде того, что при накатывании pl/SQL разваливаться RAC кластер. Систему деплоя и версионирования писали сами. И сотни других проблем, которых просто а не возникает при использовании с любого внешнего языка. В общем, эти пакеты процедур по несколько тысяч строк до сих пор приходят когда мне в кошмарах. Хотя вначале кажется, что всё тоже весело, и мы тоже писали отправку почты через PL/SQL.
Ни в коем случае не говорю, что хранимые процедуры это зло — есть масса случаев, когда они быстры и удобны. Но писать на них сервер приложений для большого проекта это примерно как прыгать в пропасть, страхуясь верёвкой на шее. Сначала всё хорошо, и только ветер свистит ушах. А потом…
Мы делали примерно то же самое для системы ЕИАС с сотнями тысяч пользователей, и с тех пор, когда я слышу слово «хранимые процедуры», я хватаюсь за пистолет. Там была ещё масса всякой специфики Oracle в виде того, что при накатывании pl/SQL разваливаться RAC кластер. Систему деплоя и версионирования писали сами. И сотни других проблем, которых просто а не возникает при использовании с любого внешнего языка. В общем, эти пакеты процедур по несколько тысяч строк до сих пор приходят когда мне в кошмарах. Хотя вначале кажется, что всё тоже весело, и мы тоже писали отправку почты через PL/SQL.
Ни в коем случае не говорю, что хранимые процедуры это зло — есть масса случаев, когда они быстры и удобны. Но писать на них сервер приложений для большого проекта это примерно как прыгать в пропасть, страхуясь верёвкой на шее. Сначала всё хорошо, и только ветер свистит ушах. А потом…
В транскрипте это легко пропустить, а в докладе я несколько раз повторял «мы небольшой бизнес», «у нас маленькая команда». Суть в том, что если вы не планируете перерасти Авито, можно не бояться такого решения. Мы не планируем.
Было бы здорово, если бы вы рассказали об этом опыте подробнее.
приглашаем к нам на конференцию летом, выступить, поделиться опытом :-)
Вот этот проект. Oracle Database 11g, база >10Тб, штат из >40 человек, которые пишут и изменяют PL/SQL код, свыше 40 комплектов схожих схем (по количеству подключенных регионов РФ, нужно было отдельными схемами, поскольку проекты должны были быть отчуждаемы). Ах, да, четыре более-менее локальных СУБД и ещё 4-5 удалённых.
Редактор (PL SQL developer) не справляется с размером пакетов и часто виснет. Проливка обновлений делалась адскими баш скриптами с заменой префиксов схем. Разработчики постоянно дрались за изменения в пакетах в дев среде. Многие изменения терялись без возможности восстановления. Проливка кода на географически удалённых регионах со слабым каналом была испытанием даже для сильных духом.
При этом мы вроде не очень глупые ребята, и у команды DBA, в которую я случайно вошёл (вообще я тимлид по разработке, но жизнь заставила) были сертификаты «Oracle Database 11g Administrator Certified Professional» и «Oracle Database 11g Developer Certified Professional». Проблемы поддержки Оракла я опущу, так они нерелевантны этому посту, да и было их, честно говоря, говоря меньше, чем проблем разработки, отладки и деплоя.
В общем, есть два показательных решения, которыми я до сих пор спустя 5 лет и горжусь и стыжусь.
1. Система деплоя PL/SQL кода на разные окружения и комплекты схем. На PHP, Карл!
2. Система постфактумного версионирования PL/SQL кода в Git репозиторий в виде PHP демона. Она даже есть в паблике (осторожно, быстрокод).
И то и другие — чудовищные костыли, но экономили нам просто безумное количество времени разработки. И я до сих пор не знаю, как это сделать правильно. Я даже писал на хабр в надежде, что мне просветят — но увы, мне просто поведали, что я не понимаю, что такое миграции, и вообще дурак. К сожалению, я хорошо понимаю, что такое миграции — и использовать их в случае PL/SQL невозможно.
В общем, сейчас в другом месте я работаю тимлидом в эквайринговой сфере, и у нас нет хранимых процедур, зато есть нормальные миграции, деплой, отладка, разработка (и среда разработки), Query Builder и бизнес логика с использованием произвольной СУБД в Node.JS. И когда мне становится грустно, я просто вспоминаю, как искал дедлоки в Оракле, чтобы продолжить проливку PL/SQL кода, которая прошла только наполовину и привела базу в нерабочее состояние (или ещё сотни других кейсов)… И мне становится хорошо.
Редактор (PL SQL developer) не справляется с размером пакетов и часто виснет. Проливка обновлений делалась адскими баш скриптами с заменой префиксов схем. Разработчики постоянно дрались за изменения в пакетах в дев среде. Многие изменения терялись без возможности восстановления. Проливка кода на географически удалённых регионах со слабым каналом была испытанием даже для сильных духом.
При этом мы вроде не очень глупые ребята, и у команды DBA, в которую я случайно вошёл (вообще я тимлид по разработке, но жизнь заставила) были сертификаты «Oracle Database 11g Administrator Certified Professional» и «Oracle Database 11g Developer Certified Professional». Проблемы поддержки Оракла я опущу, так они нерелевантны этому посту, да и было их, честно говоря, говоря меньше, чем проблем разработки, отладки и деплоя.
В общем, есть два показательных решения, которыми я до сих пор спустя 5 лет и горжусь и стыжусь.
1. Система деплоя PL/SQL кода на разные окружения и комплекты схем. На PHP, Карл!
2. Система постфактумного версионирования PL/SQL кода в Git репозиторий в виде PHP демона. Она даже есть в паблике (осторожно, быстрокод).
И то и другие — чудовищные костыли, но экономили нам просто безумное количество времени разработки. И я до сих пор не знаю, как это сделать правильно. Я даже писал на хабр в надежде, что мне просветят — но увы, мне просто поведали, что я не понимаю, что такое миграции, и вообще дурак. К сожалению, я хорошо понимаю, что такое миграции — и использовать их в случае PL/SQL невозможно.
- Потому что в случае изменения трёх строк в пакете на 5000 строк у тебя получается миграция в виде огромного куска понятно чего.
- Потому что есть куча случаев, когда миграция, которая должна являться атомарной, пройдёт не до конца.
- Потому что migrate down не починит развалившиеся зависимые объекты.
- Наконец просто потому, что аналитики не хотят писать какие-то непонятные штуки, они хотят выполнять PL/SQL :)
В общем, сейчас в другом месте я работаю тимлидом в эквайринговой сфере, и у нас нет хранимых процедур, зато есть нормальные миграции, деплой, отладка, разработка (и среда разработки), Query Builder и бизнес логика с использованием произвольной СУБД в Node.JS. И когда мне становится грустно, я просто вспоминаю, как искал дедлоки в Оракле, чтобы продолжить проливку PL/SQL кода, которая прошла только наполовину и привела базу в нерабочее состояние (или ещё сотни других кейсов)… И мне становится хорошо.
Артем никогда не был настоящим программистом
Звучит, как эпитафия :)
Ух! Круто-круто!=) У нас похожий опыт, только в самом начале пошли по другому пути, postgres + сервер приложений (в котором вся бизнес логика и не только) и web приложение (достаточно громоздкое), монолитная система, и на этом всем живет бизнес оптовой торговли. Так сложилось, что мы выбрали postgres как хранилище данных, и за все время еще не пожалели. При этом у нас так же небольшая команда и сложности по разработке бизнес логики не испытываем (весь код не размыт по функциям/триггерам). Плюсы pl/pgsql, которые Вы перечислили, с небольшой оговоркой, справедливы и в нашей система, хотя pl/pgsql практически не используется.
Это всё прекрасно, но только до тех пор пока удаётся решать все поставленные задачи на pl/pgsql.
Сам пишу проекты которые работают с БД только через хранимые процедуры и представления, но от переноса бизнес-логики в БД уже отказался так как слишком медленно и сложно её реализовывать на уровне БД нежели на С++.
Хотя спорить не буду, плюсов от переноса бизнес-логики в БД хватает.
Сам пишу проекты которые работают с БД только через хранимые процедуры и представления, но от переноса бизнес-логики в БД уже отказался так как слишком медленно и сложно её реализовывать на уровне БД нежели на С++.
Хотя спорить не буду, плюсов от переноса бизнес-логики в БД хватает.
А какой это бизнес, для которого бизнес-логика быстрее работает, если все данные вынимаются наружу?
По моему опыту, для оперативной деятельности предприятия, которое занимается торговлей и производством, не нужны сложные алгоритмы. Работа финансов, склада и пр — обычная арифметика.
Для аналитики да, нужны внешние решения. Обработка изображений тоже снаружи. Но это уже не бизнес-логика.
По моему опыту, для оперативной деятельности предприятия, которое занимается торговлей и производством, не нужны сложные алгоритмы. Работа финансов, склада и пр — обычная арифметика.
Для аналитики да, нужны внешние решения. Обработка изображений тоже снаружи. Но это уже не бизнес-логика.
По моему опыту, для оперативной деятельности предприятия, которое занимается торговлей и производством, не нужны сложные алгоритмы.
Смотрите, вы сами уже выделили, что там не нужно, но это же не все сферы где бизнес-логика в БД не является не оправданной. Остаются и другие, где БД нужна, но логику извольте во вне.
У меня к примеру были геодезические задачи требующие работы с соответствующим API. Задачи автоматизации в которых производятся тяжёлые расчёты и их физически устраивать на сервере с СУБД не есть хорошее решение. Задачи с файловыми хранилищами, где обработку информации быстрее осуществить на машине и передать в СУБД итоговые данные нежели качать на сервер, особо если это пакеты файлов гигабайт+. Отдельно можно рассматривать такие системы, где нужен контроль и разграничение доступа к информации, при этом надо учитывать что стандартная модель применяемая в СУБД может и не подойти. Если идёт работа с графикой и производятся расчёты с последующим сохранением, то как то не очень эффективно гонять в БД и назад только для расчётов.
Если задача решается эффективно одними инструментами, то это не значит, что те же инструменты можно эффективно применить к другой задаче. Всё зависит от целей, средств и знаний.
Конечно же, специализированные области нуждаются в middleware. Только на 100тыс компаний налогоплательщиков хорошо если 100 занимаются чем-то вроде картографии. Большинство торгуют, хранят, производят. И 95% задач — учет денег, товаров и труда. Всякая «опердень», одним словом -)
Но ИТ специалисты из этих 100тыс обычных компаний ходят на конференции и слушают о том, как mail.ru делает бигдату, как кто-то на монге построил международный проект по лайканью котиков и т.д. А потом с горящими глазами возвращаются на свои рабочие места и начинают напяливать монгу на складское хранение, писать собственные сервера приложений на CPP, шардировать базу на 20 000 клиентов, в три слоя кешировать поиск на жалком сайте, потому что ORM генерит sql запросы на 500 строк и т.д.
Но нет нужды так делать в 99.99% компаний. Вот об этом мой доклад.
Но ИТ специалисты из этих 100тыс обычных компаний ходят на конференции и слушают о том, как mail.ru делает бигдату, как кто-то на монге построил международный проект по лайканью котиков и т.д. А потом с горящими глазами возвращаются на свои рабочие места и начинают напяливать монгу на складское хранение, писать собственные сервера приложений на CPP, шардировать базу на 20 000 клиентов, в три слоя кешировать поиск на жалком сайте, потому что ORM генерит sql запросы на 500 строк и т.д.
Но нет нужды так делать в 99.99% компаний. Вот об этом мой доклад.
Sign up to leave a comment.
Сервер приложений на pl/pgsql