Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 112
Ниже Вы можете увидеть срач о том, что хранить логику в БД — это ужасно, неудобно, непереносимо, непонятно и т.д.
Полюбопытствую — что именно и как хотите снять с моделей Magento и переложить на плечи БД?
Да, утечка памяти — это проблема в PHP < 5.3, если остаются циклические ссылки и скрипт исполняется долго. Для ее решения в Magento 1.5 (1.10), которая выйдет в ближайшие пару недель, у моделей появился метод clearInstance(). У продуктов он чистит все циклические ссылки, в результате чего PHP может корректно очистить память.
Конечно, такое скрытое управление памятью в PHP < 5.3 делает сложным работу. Особенно для таких интересных архитектур как Мадженто. Но, радует, что хоть в 5.3 PHP научился уже самостоятельно убирать циклические ссылки.
Ничего нет плохого в том, чтобы перенести часть бизнес-логики на базу. Единственно что, надо быть аккуратным, так как при написании своих типов продуктов или при дальнейшем сопровождении люди уже могут забыть об этих триггерах или хранимых процедурах, и в результате будут очень удивляться происходящей магии. Да и используемые сторонние экстеншены могут быть совсем не готовы к этому.
Ну и еще — тут уже высказывались — инстансы приложения распараллелить гораздо легче, чем инстансы базы данных. Потому в высоко-нагруженных проектах лучше, все-таки, оставить бизнес-логику на стороне PHP.
Поэтому делайте (так на самом деле многие пользователи Мадженто поступают), но аккуратно. Да и с выходом 1.5 утечки памяти при импорте-экспорте продуктов решены.
Конечно, такое скрытое управление памятью в PHP < 5.3 делает сложным работу. Особенно для таких интересных архитектур как Мадженто. Но, радует, что хоть в 5.3 PHP научился уже самостоятельно убирать циклические ссылки.
Ничего нет плохого в том, чтобы перенести часть бизнес-логики на базу. Единственно что, надо быть аккуратным, так как при написании своих типов продуктов или при дальнейшем сопровождении люди уже могут забыть об этих триггерах или хранимых процедурах, и в результате будут очень удивляться происходящей магии. Да и используемые сторонние экстеншены могут быть совсем не готовы к этому.
Ну и еще — тут уже высказывались — инстансы приложения распараллелить гораздо легче, чем инстансы базы данных. Потому в высоко-нагруженных проектах лучше, все-таки, оставить бизнес-логику на стороне PHP.
Поэтому делайте (так на самом деле многие пользователи Мадженто поступают), но аккуратно. Да и с выходом 1.5 утечки памяти при импорте-экспорте продуктов решены.
Порадовало, что целых два человека добавили статью в избранное — не уж то на практике будут применять?:)
В своё время участвовал в одном «энтерпрайз»-проекте (с очень нехилой для учётных систем загрузкой), всю (по-максимуму) логику (в т.ч. CRUD) делали на хранимках в T-SQL. По-моему достаточно логично. Переносимость — не знаю на сколько она важна, реально в жизни не сталкивался с нужностью перехода с одной СУБД на другую. Единственный заметный минус — дублирование логики, валидации например. А производительность и масштабируемость, на сколько я понял из практики, выигрывает. Так что почему бы аналогично с MySQL не попробовать…
Боюсь, у всех с опытом разработки от 5 лет есть подобный опыт, в том числе и у меня. Действительно порой оправданно с точки зрения производительности.
А почему боитесь-то, не понял? Или Вы о переходе на другую СУБД?
Кроме производительности бывает еще и потребность атомарности в ситуациях вида SELECT + расчёт-на-клиенте + UPDATE/INSERT. Лочить таблицы — херить производительность, а транзакции не спасут из-за неоткатываемости клиентского пересчёта. Вот тогда и выручают stored proc и триггеры.
Забыл уточнить, что при этом вне хранимок не было ни строчки SQL-кода (работа с БД происходила исключительно через обращение к хранимым процедурам). Думается мне что это очень неплохо с точки зрения защиты от SQL-иньекций и ошибок строковой логики.
Поделитесь чем профилировали процедуры и делали отладку?
Вы будете смеяться, но таки ничем. Исключительно вручную и на глаз. Если бы знать для этого какие-то удобные инструменты, сэкономили бы уйму времени. Может Вы можете что-то порекомендовать? Сейчас говорят уже вроде в Visual Studio 2010 что-то такое появилось.
(SQL Management Studio / VS) < 2005
SQL Profiler, SQL Plan Analizer, ну и есть разные продукты от Red Gate
SQL Profiler, SQL Plan Analizer, ну и есть разные продукты от Red Gate
неужто ты умудрился из одного слова ТРИ сделать!
На вопрос «где надо хранить логику данных?» может ответить здравый смысл. Им можно пользоваться не опасаясь, что это «не лучший подход».
Ребята, а чего вы все такие серьезные? Это топик just-for-fun. Просто мне захотелось проверить, можно ли так сделать. А вы тут действительно развернули холивар на тему «так делать низзя».
Минус который я вижу — непереносимость кода.
Приложение привязано в конкретной БД, либо повышается стоимость разработки.
Приложение привязано в конкретной БД, либо повышается стоимость разработки.
>то вы пишите запросы по второму разу и вы не сможете дать гарантию того, что бизнес логика работы БД не нарушена.
Во-первых, что значит «бизнес логика работы БД не нарушена». Если хранимок нет — нет и бизнес логики в БД.
Во-вторых, для персистентных состояний (если они нужны) существуют транзакции.
Во-первых, что значит «бизнес логика работы БД не нарушена». Если хранимок нет — нет и бизнес логики в БД.
Во-вторых, для персистентных состояний (если они нужны) существуют транзакции.
Дорогой друг! Есть прямо противоположная ситуация. Вы, видимо, никогда не меняли свою БД. Представьте ситуацию, когда стоит задача сменить СУБД (смена предпочтений клиента, смена главного архитектора, пожелания «директора», да мало ли ситуаций). В своём случае я использую ORM и модели использующие этот самый ORM. Дык вот я просто сменю бекэнд в ORM-е и продолжу работать как ни в чем не бывало. А что сделаете вы? А если ранее ваши «хранимки» были заточены под Oracle, а теперь нужен MS SQL? А если нужно поддерживать несколько СУБД? А если среди них будет СУБД без «хранимок», а заказчик хочет всенепременно?
И да, в моём случае никакого SQL в коде нет вообще, ORM позволяет мне гибко оперировать структурами данных целевого языка, являясь инструментом для создания гибких высокоуровневых моделей. И эти модели даже не заметят смены СУБД.
Такой вот не менее поучительный квест.
И да, в моём случае никакого SQL в коде нет вообще, ORM позволяет мне гибко оперировать структурами данных целевого языка, являясь инструментом для создания гибких высокоуровневых моделей. И эти модели даже не заметят смены СУБД.
Такой вот не менее поучительный квест.
видимо в вашем коде не было никогда серьезных отчетов, в любом орм это выливается в здоровенный кусок на чистом SQL, потому как делать такое средствами орм крайне затратно по производительности.
орм конечно круто и модный тренд, но далеко не панацея и накладывает свои ограничения.
и даже с орм миграция с одной базы на другую, даже SQL -> SQL, всегда заканчивается полным геморроем (если конечно проект не в 3 строчки и 2 формочки). Это еще тот вопрос что проще смигрировать хранимки или поменять орм адаптер.
орм конечно круто и модный тренд, но далеко не панацея и накладывает свои ограничения.
и даже с орм миграция с одной базы на другую, даже SQL -> SQL, всегда заканчивается полным геморроем (если конечно проект не в 3 строчки и 2 формочки). Это еще тот вопрос что проще смигрировать хранимки или поменять орм адаптер.
Был опыт перевода довольно крупного проекта с MS SQL на MySQL. До этого в качестве ORM был Linq2Sql. Купил devart dotConnect, поменял в одном месте дата контекст и коннекшн стринг и всё заработало. Опен-сорс варианты, увы, работали хуже.
А вот для отчётов был другой фронтенд, и там юзались хранимки. А в мускуле синтаксис другой, пришлось попотеть. И, на удивление, жирные запросы работали намноооого медленне MS SQL.
А вот для отчётов был другой фронтенд, и там юзались хранимки. А в мускуле синтаксис другой, пришлось попотеть. И, на удивление, жирные запросы работали намноооого медленне MS SQL.
>И, на удивление, жирные запросы работали намноооого медленне MS SQL.
А что, собственно, удивительного? MS SQL, как ни крути, а гораздо более продуманная и производительная СУБД чем MySQL. Ну, может быть последние фишки с HandlerSocket позволяют говорить что MySQL производительнее MS SQL _в отдельных случаях_. Но в целом мускулю и по производительности и по удобству до МСа еще расти и расти.
А что, собственно, удивительного? MS SQL, как ни крути, а гораздо более продуманная и производительная СУБД чем MySQL. Ну, может быть последние фишки с HandlerSocket позволяют говорить что MySQL производительнее MS SQL _в отдельных случаях_. Но в целом мускулю и по производительности и по удобству до МСа еще расти и расти.
А давайте «по-менеджерскому» или «аналитически»? Я не конкретизировал языки, а в разных языках ORM-ы некисло отличаются по возможностям и производительности. Я к тому, что оценки разные.
Собственно, давайте оценивать затраты. Что именно переписывать для новой субд? Я вот экспериментировал с тремя, начал с mysql, потом postrgre и ради интереса mssql. Собственно, переписывание заключалось в создании вьюшек и процедур для mssql, и то для эксперимента. В целом же вся система отработала отлично. Но с точки зрения аналитики, затраты на переписывание+отладку всех полностью процедур под новую СУБД сравнимы с затратами на корректировку высокоуровневой модели?
А остальное вполне себе реальность на мелко-средних проектах, но никак не раздувание. Были моменты, когда у заказчика менялись предпочтения, были моменты смены философии у начальства/проектировщиков, по всякому. Но мы же хотим аналитически? Давайте оценим все ситуцации. Для простоты их две. Смена языка: тут вопрос в поддержке нужных функциональностей в ORM-е в нужном языке. Чаще всего базовый функционал таблицы+связи есть везде, вопрос в производительности. Второй момент в смене СУБД. Если уж мы оцениваем аналитически, то в целом ответ очевиден.
А итог очевиден, для каждой ситуации своё решение, о чём я и хотел сказать. В тех ситуациях, когда ТЗ чёткое, заказчик подписался и никто ничего менять не будет ибо документы и прочее, тогда низкоуровневая оптимизация и целевые решения вполне при деле. Но я бы не брал в это дело.нет или яву, они смажут весь эффект от оптимизации. А вот там, где точных целей нет, где всё шатко, а таких проектов подавляющее большинство, где задачи и целим меняются часто (хвала ебучему аджайлу), в этот моменте гибкость ORM-а и модели на его основе отлично прикрывают зад и позволяют спасти время и деньги, потеряв не так много.
Что мне не понравилось выше, так это категоричность, типа «мой мнение завсегда верно». Именно против этого я и выступал в форме равного противоречия.
Собственно, давайте оценивать затраты. Что именно переписывать для новой субд? Я вот экспериментировал с тремя, начал с mysql, потом postrgre и ради интереса mssql. Собственно, переписывание заключалось в создании вьюшек и процедур для mssql, и то для эксперимента. В целом же вся система отработала отлично. Но с точки зрения аналитики, затраты на переписывание+отладку всех полностью процедур под новую СУБД сравнимы с затратами на корректировку высокоуровневой модели?
А остальное вполне себе реальность на мелко-средних проектах, но никак не раздувание. Были моменты, когда у заказчика менялись предпочтения, были моменты смены философии у начальства/проектировщиков, по всякому. Но мы же хотим аналитически? Давайте оценим все ситуцации. Для простоты их две. Смена языка: тут вопрос в поддержке нужных функциональностей в ORM-е в нужном языке. Чаще всего базовый функционал таблицы+связи есть везде, вопрос в производительности. Второй момент в смене СУБД. Если уж мы оцениваем аналитически, то в целом ответ очевиден.
А итог очевиден, для каждой ситуации своё решение, о чём я и хотел сказать. В тех ситуациях, когда ТЗ чёткое, заказчик подписался и никто ничего менять не будет ибо документы и прочее, тогда низкоуровневая оптимизация и целевые решения вполне при деле. Но я бы не брал в это дело.нет или яву, они смажут весь эффект от оптимизации. А вот там, где точных целей нет, где всё шатко, а таких проектов подавляющее большинство, где задачи и целим меняются часто (хвала ебучему аджайлу), в этот моменте гибкость ORM-а и модели на его основе отлично прикрывают зад и позволяют спасти время и деньги, потеряв не так много.
Что мне не понравилось выше, так это категоричность, типа «мой мнение завсегда верно». Именно против этого я и выступал в форме равного противоречия.
Ну вообще-то можно использовать и хранимки, и ORM. То есть какую-то специфическую и жутко тормозную выборку засунуть в процедуру, а в ORM дергать метод, который будет это всё возвращать уже в объектах.
Когда нужно было сделать третьего клиента к БД, то создал веб-сервис, который работал с БД, а клиенты обращались только к нему :)
Вива! Наконец-то, хоть кто-то вспомнил про трёхуровневую архитектуру! )
Это когда производительностью можно в допустимой степени пренебречь. Когда все супер-пупер-критично, то написание процедур оказаться выгоднее (в плане трудозатрат) написания модулей на С-ях.
Но все равно пятерку за паттерн Интерфейс вы получаете )
Но все равно пятерку за паттерн Интерфейс вы получаете )
надо разделять приложение на три части — данные, UI и так называемая «бизнесс-логика».
Эту «бизнесс-логику» реализуем на том же самом php в отдельных классах. И, когда нам понадобятся клиенты на C#, публикуем эти класс в виде (к примеру) web-сервиса и работам только с ними.
Получаем тоже самое, только вместо ХП — методы сервиса.
Эту «бизнесс-логику» реализуем на том же самом php в отдельных классах. И, когда нам понадобятся клиенты на C#, публикуем эти класс в виде (к примеру) web-сервиса и работам только с ними.
Получаем тоже самое, только вместо ХП — методы сервиса.
Если думать об этом заранее, то можно написать приложение так, чтобы создание API занимало минут 5.
Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.
XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.
XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
Поверьте пользовался, но это был большой корпоративный интранет проект java + oracle.
О другой БД речи не шло.
В webdev все несколько иначе. Есть проект php/perl/ruby/python + mysql. В некоторый момент при превышении нагрузки необходимо перейти на тот же postgresql.
Вот тут action record решения и являются наиболее гибкими.
О другой БД речи не шло.
В webdev все несколько иначе. Есть проект php/perl/ruby/python + mysql. В некоторый момент при превышении нагрузки необходимо перейти на тот же postgresql.
Вот тут action record решения и являются наиболее гибкими.
Пробовал когда-то (не для веба) — отпугнуло неудобство разработки хранимок и ограниченный функционал (сейчас может поменялось, но тогда не нашёл способа динамически менять имя таблицы в запросе).
1. Правильно написанные хранимые процедуры способны разгрузить базу (не забываем про навороченный оптимизатор SQL-запросов в любой субд)
2. Да, но сколько ж вы туда собираетесь загнать кода, что вам нужна команда DBA?
3. Проверять логику на продакшене? Хм…
Есть у такого подхода один убойный плюс, про который все почему-то забыли. Это безопасность. Можно закрыть доступ к обычным селектам-апдейтам и делать все через хранимые процедуры. Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.
Это почти стандарт при разработке например банковских систем.
2. Да, но сколько ж вы туда собираетесь загнать кода, что вам нужна команда DBA?
3. Проверять логику на продакшене? Хм…
Есть у такого подхода один убойный плюс, про который все почему-то забыли. Это безопасность. Можно закрыть доступ к обычным селектам-апдейтам и делать все через хранимые процедуры. Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.
Это почти стандарт при разработке например банковских систем.
1.А неправильно написанные способны ложить базу
2.Базу действительно лучше писать одному ИМХО.
Хранимые процедуры имеют мало общего с бизнес-логикой. С нормальной бизнес-логикой. Разумеется почти всё можно сделать на SP и T-SQL но это такой тупиковый геморой. Особенно быстро это становится понятным при работе с несколькими базами, при репликациях и т д.
А безопасность да.
2.Базу действительно лучше писать одному ИМХО.
Хранимые процедуры имеют мало общего с бизнес-логикой. С нормальной бизнес-логикой. Разумеется почти всё можно сделать на SP и T-SQL но это такой тупиковый геморой. Особенно быстро это становится понятным при работе с несколькими базами, при репликациях и т д.
А безопасность да.
1. Не аргумент — для этого есть тестирование.
2. На примере Oracle — действительно крупную задачу удобно разбить на части и реализовывать в разных пакетах (например) разными разработчиками. И да, есть варианты реализации в БД вышеупомянутых «крупных задач».
В остальном да, идея не новая, спорная, но… вариант :)
2. На примере Oracle — действительно крупную задачу удобно разбить на части и реализовывать в разных пакетах (например) разными разработчиками. И да, есть варианты реализации в БД вышеупомянутых «крупных задач».
В остальном да, идея не новая, спорная, но… вариант :)
Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.
Что ему помешает вызывать процедуры? Через процедуры слить нужную инфу? Чучка больше времени?
Это почти стандарт при разработке например банковских систем.
нема такого стандарта, не почти, никак.
Эээ, что, простите? У вас нема такого стандарта? Э…
Вот представьте себе таблицу «юзеры». Пароль SQL-суперадмина от «боевой» бд есть только у сурового начальника службы безопасности. Заводить и редактировать юзеров может только он (ну ок, «мальчик» от его имени).
У обычных клиентов (читай программистов банковского приложения) есть только очень усеченная в правах учетная запись. Без права выполнять селекты, инсерты или апдейты на таблице юзеров. Есть только доступ к одной хранимой процедуре, которая по паре параметров (логин, хэш пароля) либо возвращает 1 строку с профилем текущего пользователя, либо — если логин или хэш пароля не верны — возвращает ноль строк.
Ну вперед, слейте в таком конфиге таблицу «юзеры». Или хотя бы пары «логин — хэш пароля».
Вот представьте себе таблицу «юзеры». Пароль SQL-суперадмина от «боевой» бд есть только у сурового начальника службы безопасности. Заводить и редактировать юзеров может только он (ну ок, «мальчик» от его имени).
У обычных клиентов (читай программистов банковского приложения) есть только очень усеченная в правах учетная запись. Без права выполнять селекты, инсерты или апдейты на таблице юзеров. Есть только доступ к одной хранимой процедуре, которая по паре параметров (логин, хэш пароля) либо возвращает 1 строку с профилем текущего пользователя, либо — если логин или хэш пароля не верны — возвращает ноль строк.
Ну вперед, слейте в таком конфиге таблицу «юзеры». Или хотя бы пары «логин — хэш пароля».
У нас есть довольно крупный проект, написанный на MSSQL/.Net/XSLT в котором используется как раз такой подход. Вообще да, это работает, но у подхода довольно много недостатков, например сложнее горизонтально масштабировать, ошибки в коде хранимок часто невозможно отследить в силу того, что код не компилируется, я уже молчу про юнит-тесты для этого добра.
П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
Проблемы, описанные Вами, существуют для более ранних технологий MS.
1. Сейчас есть возможность писать хранимки на c#. Соответственно, Вы можете в них прописывать соединение к внешнему SQL серверу. И, таким образом, производить горизонтальное масштабирование. Попутно к этому можно много на дублирующем сервере привязать.
2. Сейчас хранимки пошагово отлаживаются. В т.ч. на tsql.
Попробуйте MS SQL 2008 + Visual Studio 2010. Проект типа database и вперёд. Это неимоверное удовольствие.
1. Сейчас есть возможность писать хранимки на c#. Соответственно, Вы можете в них прописывать соединение к внешнему SQL серверу. И, таким образом, производить горизонтальное масштабирование. Попутно к этому можно много на дублирующем сервере привязать.
2. Сейчас хранимки пошагово отлаживаются. В т.ч. на tsql.
Попробуйте MS SQL 2008 + Visual Studio 2010. Проект типа database и вперёд. Это неимоверное удовольствие.
Я про все это прекрасно знаю.
1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
2. Знаю. Помогает не сильно.
Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
2. Знаю. Помогает не сильно.
Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
Ну я в принципе предполагал, что увлечённый человек это попробовал. =)
Тогда, если не возражаете, я хотел бы Вас немного помучить.
1. Если сравнить 2-х звенку с логикой в БД и 3-хзвенку (web не рассматриваем, т.к. другие случаи). То неужто (по Вашему мнению) геморней писать логику в БД, чем пилить трёхзвенку? Тут же и частей больше, и удобства при программировании меньше и т.д.
2. А вообще апдейты и поддержка клиентов при логике в БД насколько проблемны? Потому что код поменять — это dll переподключить новую. Но если ещё структура меняется, да если ещё пользователи работают. По горячему (когда пользователи работают) вообще это возможно делать?
3. Коллективная разработка в случае логики в БД насколько проблемна? Какие основные проблемы?
Спасибо.
Тогда, если не возражаете, я хотел бы Вас немного помучить.
1. Если сравнить 2-х звенку с логикой в БД и 3-хзвенку (web не рассматриваем, т.к. другие случаи). То неужто (по Вашему мнению) геморней писать логику в БД, чем пилить трёхзвенку? Тут же и частей больше, и удобства при программировании меньше и т.д.
2. А вообще апдейты и поддержка клиентов при логике в БД насколько проблемны? Потому что код поменять — это dll переподключить новую. Но если ещё структура меняется, да если ещё пользователи работают. По горячему (когда пользователи работают) вообще это возможно делать?
3. Коллективная разработка в случае логики в БД насколько проблемна? Какие основные проблемы?
Спасибо.
1. В случае с 2-х звенкой у вас в БД просто неявно будет спрятано два уровня — логики и доступа к данным. В противном случае очень сложно, а то и вовсе невозможно будет организовать юнит-тесты бизнес-логики, а без них жить очень сложно. Соответственно, в общем случае нет никакой разницы, где находится логика — на сервере БД или на middle-tier сервере, а так как последний проще масштабируется, то выбор очевиден. Конечно, если приложение небольшое и развивать его не планируют, то 2-х звенка банально дешевле, поэтому стоит выбирать ее. В таком случае 3-х звенка это как использовать паттерн MVC для домашней странички с фотографией кота — профита никакого, а затраты непропорционально огромны, лучше написать простейший скрипт на РНР. Но если ваш проект куда больших масштабов то нужны другие подходы.
2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).
3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.
В общем, по моему личному мнению, чем больше вы отвязываетесь от БД, тем легче вам жить. Но это мнение основано на моем опыте разработки довольно специфического корпоративного софта.
2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).
3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.
В общем, по моему личному мнению, чем больше вы отвязываетесь от БД, тем легче вам жить. Но это мнение основано на моем опыте разработки довольно специфического корпоративного софта.
Рискну выразить свое мнение.
Тот кто не работал с SQL — системами у которых бизнес — логика размещена на сервере, даже не представляют насколько это ОБАЛДЕННАЯ вещь!
2 сек. и все работают по новым правилам!
Естественно что ресурс SQL — Server (это проблема кластера..) пожирается с огромной скоростью (но это зависит уже от реализации), но с точки зрения поддержки бизнес-систем это еще раз ОБАЛДЕННЫЕ условия работы!
Не нужно так строго и однозначно говорить «бизнес-логика на SQL» — это плохо…
Видел я «популярные» бизнес-системы, в которых на производстве пользователей выбивали из сессий по графику…
Для работы в WEB — оценить не могу… слаб я в этом вопросе.
Тот кто не работал с SQL — системами у которых бизнес — логика размещена на сервере, даже не представляют насколько это ОБАЛДЕННАЯ вещь!
2 сек. и все работают по новым правилам!
Естественно что ресурс SQL — Server (это проблема кластера..) пожирается с огромной скоростью (но это зависит уже от реализации), но с точки зрения поддержки бизнес-систем это еще раз ОБАЛДЕННЫЕ условия работы!
Не нужно так строго и однозначно говорить «бизнес-логика на SQL» — это плохо…
Видел я «популярные» бизнес-системы, в которых на производстве пользователей выбивали из сессий по графику…
Для работы в WEB — оценить не могу… слаб я в этом вопросе.
Добавлю:
нужно очень хорошо заранее продумать и построить систему.
Но это действительно сложно. :(
и не на уровне ЦПШ это делается
:) ЦПШ — это не Центральная Партийная школа КПСС
а Церковно — приходская школа…
это приходит потом… в зависимости от понимания МИРОВЫХ ТЕНДЕНЦИЙ РАЗВИТИЯ
Sorry… если кого — то обидел.
нужно очень хорошо заранее продумать и построить систему.
Но это действительно сложно. :(
и не на уровне ЦПШ это делается
:) ЦПШ — это не Центральная Партийная школа КПСС
а Церковно — приходская школа…
это приходит потом… в зависимости от понимания МИРОВЫХ ТЕНДЕНЦИЙ РАЗВИТИЯ
Sorry… если кого — то обидел.
Ой.
Еще уточнение…
ЦПШ = ХТМЛ + ПХП + JS
Еще уточнение…
ЦПШ = ХТМЛ + ПХП + JS
ааааааааааа маньяки на Хабре… :)
Где-то встречался с аргументом в пользу такого подхода применительно к Oracle: сколько веб-технологий сменилось за время существования PL/SQL? Да он существовал все то время, что вообще существует веб. Технологии постоянно меняются, а PL/SQL лишь расширяется и весь старый код более-менее работает. Люди городят хитрые абстракции для доступа к БД на случай ее смены, но гораздо чаще меняется не БД, а сама веб-технология.
На самом деле хранить логику в базе довольно удобно (по крайней мере в случае с Oracle). То что делается на middle tier достаточно объемным кодом, на PL/SQL зачастую делается парой строк, а работает быстрее и надежнее, ведь данные не нужно никуда гонять и с транзакциями проще.
Проблемы действительно начинаются на больших проектах из-за сложностей с управлением версиями, тестированием и, конечно, масштабированием. Но для небольших проектов хранить логику в хорошей СУБД — это незаслуженно непопулярный подход. Вполне можно им пользоваться.
На самом деле хранить логику в базе довольно удобно (по крайней мере в случае с Oracle). То что делается на middle tier достаточно объемным кодом, на PL/SQL зачастую делается парой строк, а работает быстрее и надежнее, ведь данные не нужно никуда гонять и с транзакциями проще.
Проблемы действительно начинаются на больших проектах из-за сложностей с управлением версиями, тестированием и, конечно, масштабированием. Но для небольших проектов хранить логику в хорошей СУБД — это незаслуженно непопулярный подход. Вполне можно им пользоваться.
небольшие проекты не в состоянии пользоваться дарами Oracle (не по карману точнее), это удел больших интерпрайзов.
Есть такое дело, но я подозреваю что в других СУБД с этим сейчас уже тоже получше стало. Просто не писал под них в этом стиле, поэтому делюсь тем, с чем работал.
Небольшие проекты пользуются дарами postgresql.
А кроме Oracle других SQL — нет?
MS SQL Express разных версий…
сейчас там ограничения вполне достойные…
даже для реальной жизни их хватает… И ресурсы не очень большие…
MS SQL Express разных версий…
сейчас там ограничения вполне достойные…
даже для реальной жизни их хватает… И ресурсы не очень большие…
а oracle xe уже не торт? ;-)
И он замечательно отлаживается пошагово в IBExpert, например.
Но писать большие куски кода на PL/SQL — это сильная боль в седалище… Наверное, это вопрос компромиссов…
Скорее вопрос привычки. Сам PL/SQL не так уж и плох. Та же интеграция SQL'а очень удобна. Но да, он отличается от того на чем обычно программируют сегодня и требует определенной перестройки. Например почти полного отказа от ООП, ибо там с ним плохо, да и не удобна работа с данными в ООП без ORM. Но если подумать, то в бизнес-задачах возможности ООП вообще мало где используются сегодня. В основном классы являются просто структурными единицами, с чем вполне могут справиться и пакеты. Есть конечно любители rich-моделей (я и сам в их числе), но это не мейнстрим. Практически любой современный фреймвок вынуждает отказаться от развитого объектного проектирования и остановиться на какой-то не совсем логичной и совсем не компактной, но зато стандартной структуре.
В общем, если не относится к PL/SQL как к злу, а воспринять это как возможность поработать в другом стиле, то он не особо раздражает. Раздражает только отсутствие человечных IDE. При всей строгости PL/SQL'я IDE могла бы делать там очень много всего, но не делает или делает не удобно.
В общем, если не относится к PL/SQL как к злу, а воспринять это как возможность поработать в другом стиле, то он не особо раздражает. Раздражает только отсутствие человечных IDE. При всей строгости PL/SQL'я IDE могла бы делать там очень много всего, но не делает или делает не удобно.
А как же стандартные IDE для оракла — TOAD, SQL Navigator, PL/SQL developer и SQL Developer?
Там даже дебаггинг есть, и SVN прикручен к SQL Developer.
Там даже дебаггинг есть, и SVN прикручен к SQL Developer.
Не удобные и туговатые они по сравнению с хорошими IDE для Java, например.
Есть такое, особенно оракловый SQL Developer. А вот PL/SQL developer достаточно шустрый, что особенно в нем нравится — автоматическое создание новых коннектов к базе для нового окна. Не нравится — не может делать одновременных коннектов к разным базам.
Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
На самом деле в любой приличной Java IDE штатно или через плагины можно выполнять запросы и смотреть результаты. Естественно, это далеко не основная фича, поэтому она обычно реализована довольно примитивно.
Но в целом дело вряд ли в памяти, потому что у тех же Java IDE, например, создается и поддерживается гигантский индекс для code completition по всем пакетам, классам, методам, полям, переменным, xml'кам etc. Причем он строится и по коду который пишется вот прямо сейчас и может быть вообще не валидным. Разработчики всех этих IDE потратили уже столько сил на эту фичу, что она реально работает настолько круто и удобно, что писать без нее или с каким-то примитивным комплетишеном вроде того, что можно встретить в каком-нибудь TOAD'е, как-то не комфортно.
Таких фич там, причем, много. Тот же человечный автоматический рефакторинг. Всякие кодогенераторы, хинты, кододописывалки и так далее. Все это сильно ускоряет процесс.
Я не думаю что редакторы PL/SQL или другого языка хранимых процедур когда-нибудь дойдут до чего-то подобного — просто слишком маленький рынок. Как и для Scala, к примеру, которая мне очень нравится, но писать на ней я не могу, ибо при всей ее выразительности на Java выходит быстрее. Потому что для нее есть хорошие IDE, а для Scala пока только ущербные плагины к ним.
Но в целом дело вряд ли в памяти, потому что у тех же Java IDE, например, создается и поддерживается гигантский индекс для code completition по всем пакетам, классам, методам, полям, переменным, xml'кам etc. Причем он строится и по коду который пишется вот прямо сейчас и может быть вообще не валидным. Разработчики всех этих IDE потратили уже столько сил на эту фичу, что она реально работает настолько круто и удобно, что писать без нее или с каким-то примитивным комплетишеном вроде того, что можно встретить в каком-нибудь TOAD'е, как-то не комфортно.
Таких фич там, причем, много. Тот же человечный автоматический рефакторинг. Всякие кодогенераторы, хинты, кододописывалки и так далее. Все это сильно ускоряет процесс.
Я не думаю что редакторы PL/SQL или другого языка хранимых процедур когда-нибудь дойдут до чего-то подобного — просто слишком маленький рынок. Как и для Scala, к примеру, которая мне очень нравится, но писать на ней я не могу, ибо при всей ее выразительности на Java выходит быстрее. Потому что для нее есть хорошие IDE, а для Scala пока только ущербные плагины к ним.
Одно уточнение — отладка есть не в IDE, а в самом Oracle (DBMS_DEBUG). В IDE просто интерфейс к нему.
Не знаю, может я такой привередливый, но мне много всего не хватает в PL/SQL. Не хватает элементарных структур данных (нормальных, а не прикоцаных коллекций), не хватает механизмов манипуляции этими данными.
А некоторые «приёмы» заставляют меня вспомнить о залихватском сишно-ассемблерном детстве:
Для тех, кто не в теме — это сортировка коллекции PL/SQL-style :)
А некоторые «приёмы» заставляют меня вспомнить о залихватском сишно-ассемблерном детстве:
declare
x s_t := s_t('C', 'A', 'B');
begin
for s in (select column_value from (table (x))
order by column_value)
loop
dbms_output.put_line(s.column_value);
end loop;
end;
Для тех, кто не в теме — это сортировка коллекции PL/SQL-style :)
Интересны похожие статьи про разработку на Python&Postgres (для использования на практике). С MySQL такого делать не хочется…
Для одного проекта, делал похожую реализацию для бэкенда, но и то — использовал Postgres.
Возможно, что для некоторых задач — такой подход оптимален.
Но в большинстве случаев — проще использовать более привычные/традиционные технологии. Особенно, когда в разработке/поддержке принимают участие несколько человек.
Возможно, что для некоторых задач — такой подход оптимален.
Но в большинстве случаев — проще использовать более привычные/традиционные технологии. Особенно, когда в разработке/поддержке принимают участие несколько человек.
У нас на Oracle пара совсем не маленьких проектов так и сделаны.
Очень удобно — клиенты на Java, Delphi и Web. Отладка по шагам присутствует.
Всем нравится, все довольны.
Но не буду утверждать, что так надо делать всегда.
Очень удобно — клиенты на Java, Delphi и Web. Отладка по шагам присутствует.
Всем нравится, все довольны.
Но не буду утверждать, что так надо делать всегда.
Какая у Вас версия Oracle? У нас до 10.2.1.5 (дай бог памяти, вроде так) дебаггер PL/SQL мерзенько вис по любому поводу…
У нас — 9i, правда в качестве инструмента для дебагинга у одних PL/SQL, у других DevArt OraDeveloper Studio
Сейчас этот продукт называется dbForge Studio for Oracle, по дебаггеру www.devart.com/dbforge/oracle/studio/oracle-sql-debugger.html
На самом деле не ново. Работал в компании. Там все было подвешено на Oracle. Как факт она была необходима. Так вот для вывода всей аналитики, статистики и т.д. был разработан похожий фреймворк. Он даже код генерировал сам. Не MVC конечно. Но использовать было на самом деле удобно. Учитывая, что разработка и логики и интерфейса была на одном языке. Это конечно не супербонус, но затея имеет право на жизнь.
Я и не говорил, что это ново. Я ссылаюсь в тексте статьи на проект, в котором был применен подобный подход еще в 2006 году. Тогда у меня и родилась идея опробовать данный подход на MySQL с его несравненно более обрезанными возможностями по реализации хранимых процедур. Просто руки до этого дошли только сейчас.
Делал как-то с товарищем один модуль к проекту. Так вот там такой подход (перенос логики в БД) оказался выгодным — он быстрее работал.
О фактическом исполнении описанном в топике — я не говорю, возможно это для кого — то толчёк.
Речь идет о самой идее «Логика — это проблема сервера» ????
Ответ в комментариях стартера «Ребята, а чего вы все такие серьезные? Это топик just-for-fun.»
извините… отстой. А зачем тогда поднимать тему?
Я принимаю тему как вопрос «Есть ли жизнь на Марсе ?»
Мой ответ: Да, есть.
Вопрос ее реализации.
Если вы планируете построить долгоживущую и позволяющую дальше развиваться
систему — то у вас при использовании логики на серверной стороне — ЕСТЬ ПЕРСПЕКТИВЫ
железо развивается намного быстрее ПО ( пока ), есть много разных способов…
Если вы хотите всю логику своей системы положить на клиента — да у вас есть фора… несколько месяцев
(или небольшое количество лет)
В идеале ( утрирую естественно… )
у меня есть телефон!
я все свои обязанности по могу выполнить через него!
( к грузчикам это не относится )
Мы говорим о том, что ИТ может дать менеджерам, независимо то того какого уровня эти менеджеры.
а по жизни… мы на них работаем ( нагружаем «лишними» галочками конечного пользователя, чтобы потом дать манаГерам красивые отчеты, которые они нам готовы оплачивать… и т. д.
и в конце концов ( некоторые) — дают понять что кто-то или что-то мешает данной компании.
Это идеал…
а на самом деле и сейчас и всегда — информация -это повод для размышления.
Мы со своей стороны даем информацию для принятия решения…
ааааааааааааааааА на ТОЙ стороне сидит ДЕБ*Л
и что вы можете сделать?
Не переоценивайте свои возможности.
ИТ, по сути — всегда на тонну стали ( молока, сала, или молока )
Речь идет о самой идее «Логика — это проблема сервера» ????
Ответ в комментариях стартера «Ребята, а чего вы все такие серьезные? Это топик just-for-fun.»
извините… отстой. А зачем тогда поднимать тему?
Я принимаю тему как вопрос «Есть ли жизнь на Марсе ?»
Мой ответ: Да, есть.
Вопрос ее реализации.
Если вы планируете построить долгоживущую и позволяющую дальше развиваться
систему — то у вас при использовании логики на серверной стороне — ЕСТЬ ПЕРСПЕКТИВЫ
железо развивается намного быстрее ПО ( пока ), есть много разных способов…
Если вы хотите всю логику своей системы положить на клиента — да у вас есть фора… несколько месяцев
(или небольшое количество лет)
В идеале ( утрирую естественно… )
у меня есть телефон!
я все свои обязанности по могу выполнить через него!
( к грузчикам это не относится )
Мы говорим о том, что ИТ может дать менеджерам, независимо то того какого уровня эти менеджеры.
а по жизни… мы на них работаем ( нагружаем «лишними» галочками конечного пользователя, чтобы потом дать манаГерам красивые отчеты, которые они нам готовы оплачивать… и т. д.
и в конце концов ( некоторые) — дают понять что кто-то или что-то мешает данной компании.
Это идеал…
а на самом деле и сейчас и всегда — информация -это повод для размышления.
Мы со своей стороны даем информацию для принятия решения…
ааааааааааааааааА на ТОЙ стороне сидит ДЕБ*Л
и что вы можете сделать?
Не переоценивайте свои возможности.
ИТ, по сути — всегда на тонну стали ( молока, сала, или молока )
Однако сия замечательная функция не работает применительно к MySQL. Потому...
надо было оставить MySQL. Не для этого она.
PS
данный подход имеет место для систем со сложной БД и логикой, особенно когда с БД работает более одного приложения. в данном случае, наличие единого согласованного api на уровне субд это плюс.
В книжках по СУБД и БД написано на первой странице — база должна быть настолько простой насколько это возможно.
На личном опыте убедился что перенос бизнес-логики в базу это зло. Такой подход возможен но он учит ездить задом наперёд. Это не верно даже с точки зрения хороших манер.
Вопрос — кто-нибудь реально сталкивался с необходимостю смены платформы или базы данных? Удалось ли это сделат «щёлкнув пальцами» даже при наличие всех грамотных слоёв приложения и отряда хранимых процедур в базе?
На личном опыте убедился что перенос бизнес-логики в базу это зло. Такой подход возможен но он учит ездить задом наперёд. Это не верно даже с точки зрения хороших манер.
Вопрос — кто-нибудь реально сталкивался с необходимостю смены платформы или базы данных? Удалось ли это сделат «щёлкнув пальцами» даже при наличие всех грамотных слоёв приложения и отряда хранимых процедур в базе?
За несколько лет веб-разработки сталкивался всего однажды, совсем недавно. Проект на python (Django) переезжал на моих плечах с PostgreSQL на MySQL. ORM справился со всеми запросами, кроме одного — была какая-то выборка наискосок по всей базе данных, которая причудливо сломалась.
Есть два момента. Смотря для чего, как говорится. Для высоконагруженных систем никто не решится это делать, в частности большинство грандов вообще ушли к NoSQL базам, я логика-то вся ясное дело в коде. А вот для «обычных» приложений вполне можно. Всё зависит от ситуации, не нужно просто критично подходить. В статье описан просто способ, не более того. Жаль, без сопроводительных советов «где применять, а где нет». Самое главное, что у всего (вообще всего) есть плюсы и минусы.
Ответ на ваш вопрос: сталкиваются люди и регулярно. И, по уму, такое столкновение должно быть заложено в любой проект помноженное на вероятность/риск.
Ответ на ваш вопрос: сталкиваются люди и регулярно. И, по уму, такое столкновение должно быть заложено в любой проект помноженное на вероятность/риск.
То что «люди сталкиваются» это понятно по кругам на воде. Но я лично не встречал людей которые в здравом уме и ясной памяти «портируют» живую базу с одной СУБД на другую.
Ещё понятно если десяток таблиц. Но если это реальный монстр стянутый отношениями как паутина плюс сотен пять процедур… Мне кажется это выдавание желаемого за действительное. Всё равно прийдётся вручную всё проверять. Это если какая-нибудь база данных сайта. А если банка? Или железнодорожного узла управления.
Я бы не рискнул писать серъёзное приложение которое предполагало бы смену платформ или СУБД.
Ещё понятно если десяток таблиц. Но если это реальный монстр стянутый отношениями как паутина плюс сотен пять процедур… Мне кажется это выдавание желаемого за действительное. Всё равно прийдётся вручную всё проверять. Это если какая-нибудь база данных сайта. А если банка? Или железнодорожного узла управления.
Я бы не рискнул писать серъёзное приложение которое предполагало бы смену платформ или СУБД.
При таком подходе что будет со скоростью отработки скриптов? Вы делали какие-либо бенчмарки?
Насколько мне известно использвание хранимых процедур в MySQL несколько негативно сказывается на производительности системы, чем если бы использовались простые select-ы, insert-ы и т.п.
Насколько мне известно использвание хранимых процедур в MySQL несколько негативно сказывается на производительности системы, чем если бы использовались простые select-ы, insert-ы и т.п.
Дети, не делайте так. Работать будет и вы даже сможете написать работающее приложение. Но вы потратите время на изучение тупикового пути.
Делайте как написано в книжках — простая база, слой видов и хранимых процедур в базе, слой доступа к данным в приложении, слой бизнес-логики в приложении, слой отображения.
Эти правила как и правила дорожного движения написаны кровью!
Делайте как написано в книжках — простая база, слой видов и хранимых процедур в базе, слой доступа к данным в приложении, слой бизнес-логики в приложении, слой отображения.
Эти правила как и правила дорожного движения написаны кровью!
Биллинговые системы у Опсосов, крутящиеся на Оракле, всю логику имеют в базе — куча пакетов, процедур и функций, зачастую заврапленные с непонятными наименованиями вида kk_576_ml и т.д. Сотни пакетов и продур, тысячи таблиц, миллионы строк кода.
И все работает. И очень даже переносимо/обновляемо/разворачиваемо.
И все работает. И очень даже переносимо/обновляемо/разворачиваемо.
Имел возможность поучаствовать в двух противоположных в этом смысле проекта.
Первый проект — ентерпрайз система с толстым клиентом. Вся логика — на клиенте, юзался ОРМ. Из минусов — система уходила в глубокую задумчивость на пересчетах типа закрытия финансового года, где участие пользователя вообще не нужно. Очевидно, хранимка бы отрабатывала куда быстрее.
Второй проект — небольшое веб-приложение. Вся логика — в БД (для сравнения, кода на Джаве — 50к строк, кода на PL/SQL — 25к). Из очевидных минусов — геморройность при отладке, завязка на одного человека (DBA).
Первый проект — ентерпрайз система с толстым клиентом. Вся логика — на клиенте, юзался ОРМ. Из минусов — система уходила в глубокую задумчивость на пересчетах типа закрытия финансового года, где участие пользователя вообще не нужно. Очевидно, хранимка бы отрабатывала куда быстрее.
Второй проект — небольшое веб-приложение. Вся логика — в БД (для сравнения, кода на Джаве — 50к строк, кода на PL/SQL — 25к). Из очевидных минусов — геморройность при отладке, завязка на одного человека (DBA).
Те, кто вопит о том, что логика в БД — зло просто никогда не делал проектов со сложной логикой. Логика в БД удобна в первую очередь тем, что абсолютно не привязана к клиенту.
А меня больше всего заинтересовало, как вы сделали инициализацию приложения Zend Framework из командной строки — расскажите?
Стандартный компонент Zend_Tool. Рассказывалось и до меня тут: habrahabr.ru/blogs/zend_framework/58911/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А мы пойдем другим путем. Перемещаем модель в базу данных