А мы пойдем другим путем. Перемещаем модель в базу данных

    А мы пойдем другим путемВ последнее время веб-разработка из наколенного поделия превратилась в серьезную инженерную дисциплину. Все это стало возможным стараниями легиона специалистов, которые разработали общие практики, которые позволяют писать веб-проекты, с использованием некой архитектуры, а не подобно исследователю, сбрасывающему ящик типографского шрифта с крыши небоскреба, в надежде, что тот чудесным образом сложится в первый том «Войны и Мира». Самой распространенной парадигмой веб-программирования является, вне всякого сомнения, MVC — Model-View-Controller. Говоря примитивно, эта парадигма предусматривает разделение кода приложения на слой управления (Controller), слой представления (View) и слой управления данными (Model). При этом MVC предусматривает, что Controller и View могут (но не обязаны) зависеть от Model, в то время как Model ни при каких условиях не должен зависеть от них.
    Есть много различных подходов, как отделить бизнес-логику приложения от логики отображения и управления. Все они предусматривают, что модель является частью приложения и взаимодействует с БД, использую последнюю лишь в качестве хранилища данных. Мы же попытаемся пойти иным путем и по возможности максимально вынести бизнес-логику приложения на уровень БД.
    Предупреждение: лицам с тонкой душевной организацией лучше не видеть того, что будет твориться под катом.

    Введение


    Чтобы не быть похожим на шизофреника, скажу: в своей жизни мне довелось увидеть одно очень большое приложение, написанное похожим образом. Практически вся его бизнес-логика выполнялась на уровне БД. Было эффективно с точки зрения производительности приложения и ужасно с точки зрения производительности программиста. Правда написано оно было под ASP.NET + MS SQL Server с его, несравненно большими возможностями. Мы же будем в своих экспериментах использовать опостылевшую связку: PHP (5.3.1) + Zend Framework (1.11) + MySQL (5.1.4).
    Итак, окинем пристальным взором наш инструментарий и не будем сильно унывать (хотя есть от чего). Средства для работы с хранимыми процедурами и функциями в MySQL находятся в зачаточном состоянии, встроенной поддержки работы с хранимыми процедурами и функциями в PHP фактически нет.

    А что ваять-то будем?..


    В качестве Hello-world проекта возьмем простенький бложик с записями, комментариями и тэгами. Функционал по минимуму — наша задача просто исследовать принцип переноса модели в БД.
    В качестве программной платформы будем использовать Zend Framework.

    На штурм!


    Итак база данных у нас имеет самую простую структуру из 4 таблиц:image
    Итак, наша задача — перенести всю (или хотя бы часть) бизнес-логику в слой БД. Для этого мы будем использовать хранимые процедуры и функции, хранящиеся и выполняющиеся непосредственно на стороне сервера БД.
    Прежде всего инициализируем приложение Zend Framework из командной строки:
    zf create project ./
    zf create controller posts
    zf create controller comments
    zf create controller tags
    
    zf create action add Posts
    zf create action edit Posts
    zf create action save Posts
    zf create action delete Posts
    zf create action addComment Posts
    zf create action view Posts
    
    zf create db-table Posts sb_posts
    zf create db-table Comments sb_comments
    zf create db-table Tags sb_tags
    zf create db-table PostTags sb_post_tags
    
    zf create form Post
    zf create form Comment
    
    zf enable layout
    

    Для начала напишем процедуру по сохранению поста:
    CREATE DEFINER = 'sqlblog'@'localhost' PROCEDURE `Posts_save`(
            IN title VARCHAR(100),
            IN text TEXT,
            INOUT post_id INTEGER(11)
        )
    BEGIN
        IF ISNULL(`post_id`) OR `post_id` = 0 THEN
        	INSERT INTO `sb_posts` (`title`, `text`, `date`) 
        		VALUES (`title`, `text`, NOW());
            SET `post_id` = LAST_INSERT_ID();
        ELSE
        	UPDATE `sb_posts` AS p 
        		SET p.`title` = `title`, p.`text` = `text` 
            	WHERE p.`id` = `post_id` LIMIT 1;
        END IF;
    END;

    Первые два параметра, передаваемые в процедуру — это заголовок записи и непосредственно текст записи. Последний параметр — ID записи. Этот параметр неслучайно имеет тип INOUT. Внимательный читатель уже мог убедиться, что данная процедура имеет двойственную логику: создает запись, если post_id не передавался или передавался как 0, и обновляет запись в противном случае. После выполнения процедуры ID записи возвращается во все том же третьем параметре.
    К сожалению, удобство работы с хранимыми процедурами из PHP оставляет желать лучшего. В частности, PDO позволяет при выполнении запроса указывать, что тип передаваемого параметра INOUT. В этом случае после выполнения запроса на вызов процедуры в переменной, указанной в качестве такого параметра будет возвращено значение, возвращаемое хранимой процедурой:
    $post_id = 0;
    $sth = $dbh->prepare('CALL Posts_save(?, ?, ?)');
    $sth->bindParam(1, 'Post title', PDO::PARAM_STR);
    $sth->bindParam(2, 'Post body', PDO::PARAM_STR);
    $sth->bindParam(3, $post_id, PDO::PARAM_INT|PDO::PARAM_INPUT_OUTPUT, 11);
    $sth->execute();
    print("New post ID is: $post_id");

    Однако сия замечательная функция не работает применительно к MySQL. Потому для нормальной работы с MySQL приходится извращаться и использовать переменные самого MySQL. Трюк прост: указываем в качестве третьего параметра переменную MySQL, а потом извлекаем ее значение при помощи SELECT:
    SET @post_id = 12;
    CALL Posts_save('Post title', 'Post body', @post_id);
    SELECT @post_id AS post_id;
    Первый запрос нужен только при обновлении существующей записи.
    Для создания записи создадим следующую форму:
    class Application_Form_Post extends Zend_Form
    {
    	public function init()
    	{
    		$this
    			->addElement('hidden', 'id')
    			->addElement('text', 'title', array('label' => 'Title:', 'required' => true))
    			->addElement('textarea', 'text', array('label' => 'Text:', 'required' => true))
    			->addElement('text', 'tags', array('label' => 'Tags:', 'required' => true))
    			->addElement('submit', 'submit', array('label' => 'Add Post'));
    	}
    
    	public function prepareDecorators()
    	{
    		$this->setDecorators(array(
    			'FormElements',
    			'FormErrors',
    			'Form'
    		));
    		
    		return $this;
    	}
    }

    Теперь в коде контроллера нам достаточно написать следующее:
    class PostsController extends Zend_Controller_Action
    {
    	public function addAction()
    	{
    		$this->view->form = $form = new Application_Form_Post(array(
    			'name' => 'postForm',
    			'action' => '/posts/save/'
    		));
    		$form->prepareDecorators();
    	}
    
    	public function saveAction()
    	{
    		$post_id = $this->_getParam('id');
    		$this->view->form = $form = new Application_Form_Post(array(
    			'name' => 'postForm',
    			'action' => '/posts/save/'
    		));
    		if ($this->getRequest()->isPost()) {
    			if ($form->isValid($this->getRequest()->getPost())) {
    				$result = $this->_helper->procedure()->Posts_save(
    					$form->getValue('title'),
    					$form->getValue('text'),
    					$post_id
    				);
    				if ($post_id) {
    					$tags = $form->getValue('tags');
    					$tags = explode(',', $tags);
    					$tags = array_map('trim', $tags);
    					$this->_helper->procedure()->Post_clearTags($post_id);
    					foreach ($tags as $tag) {
    						$this->_helper->procedure()->Post_addTag($post_id, $tag);
    					}
    					$this->_redirect('/posts/view/id/' . $post_id);
    				}
    			}
    			$this->view->form = $form->prepareDecorators();
    		}
    		else {
    			$this->_redirect('/posts');
    		}
    	}
    }
    
    Расширим слегка наш функционал. Как и предполагалось, к каждому посту автор добавляет тэги, которые затем нужно выводить в виде облака. Для того, чтобы выполнить эту задачу нам необходимо на каком-то этапе вычислять вес каждого тэга. Есть несколько вариантов:
    1. Вычислять налету, запросом для каждого тэга
    2. Хранить вес каждого тэга в таблице и обновлять его при любых изменениях

    Первый вариант легко решается запросом:
    SELECT t.*, getTagWeight(t.id) AS weight FROM sb_tags AS t

    Здесь getTagWeight — заранее созданная функция, вычисляющая вес тэга. Однако, ввиду того, что облако тэгов будет выводится очень часто (гораздо чаще, чем будет изменяться порядок и состав тэгов), то такой запрос нельзя считать эффективным решением проблемы. Неплохим выходом из сложившейся ситуации было бы кэширование облака тэгов целиком, но мы попробуем решить эту проблему другим путем.
    В MySQL, начиная с версии 5.0 появился механизм триггеров — процедур, которые запускаются при выполнении некого условия. Навешивается такой триггер и срабатывать может, например, до вставки данных или после удаления. Таким образом, мы можем решить проблему вычисления весов тэгов путем навешивания двух триггеров на связующую таблицу — sb_post_tags:
    
    CREATE DEFINER = 'sqlblog'@'localhost' TRIGGER `sb_post_tags_after_ins_tr` AFTER INSERT ON `sb_post_tags`
      FOR EACH ROW
    BEGIN
    	UPDATE `sb_tags` AS t
        	SET t.`weight` = `Tag_calculateWeight`(`Tag_getById`(NEW . tag_id))
    	    WHERE t.`id` = NEW.tag_id;
    END;
    
    CREATE DEFINER = 'sqlblog'@'localhost' TRIGGER `sb_post_tags_after_del_tr` AFTER DELETE ON `sb_post_tags`
      FOR EACH ROW
    BEGIN
    	UPDATE `sb_tags` AS t
        	SET t.`weight` = `Tag_calculateWeight`(`Tag_getById`(OLD.`tag_id`))
    		WHERE t.`id` = OLD.`tag_id`;
    END;
    

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

    Выводы


    Итак, что же в сухом остатке? Простенькие проекты таким способом писать можно, но у крупных проектов при таком подходе расходы в человекочасах по моему мнению будут расти экспоненциально со сложностью проекта.
    Есть ли плюсы? Есть: это быстро. Даже по сравнению с DDD это быстро. На написание 13 процедур и 7 функций я потратил 15-20 минут. И они пишутся реально легко и просто.
    Минусы:
    • С отладкой все плохо. Я не знаю, возможна ли пошаговая отладка хранимых процедур
    • Связка PHP-Mysql применительно к хранимым процедурам работает отвратительно. Возможно, если использовать PgSQL или MSSql, то эффективность разработки можно повысить
    • В связи с некоторыми ограничениями языка MYSQL, некоторую функциональность все-таки пришлось реализовывать стандартными средствами. В частности, я говорю о постраничном выводе, так как LIMIT может принимать только константные значения, за исключением случаев, когда используется связка PREPARE/EXECUTE

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

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 112

      +68
      Ниже Вы можете увидеть срач о том, что хранить логику в БД — это ужасно, неудобно, непереносимо, непонятно и т.д.
      • НЛО прилетело и опубликовало эту надпись здесь
          +2
          Полюбопытствую — что именно и как хотите снять с моделей Magento и переложить на плечи БД?
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Да, утечка памяти — это проблема в PHP < 5.3, если остаются циклические ссылки и скрипт исполняется долго. Для ее решения в Magento 1.5 (1.10), которая выйдет в ближайшие пару недель, у моделей появился метод clearInstance(). У продуктов он чистит все циклические ссылки, в результате чего PHP может корректно очистить память.

              Конечно, такое скрытое управление памятью в PHP < 5.3 делает сложным работу. Особенно для таких интересных архитектур как Мадженто. Но, радует, что хоть в 5.3 PHP научился уже самостоятельно убирать циклические ссылки.

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

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

              Поэтому делайте (так на самом деле многие пользователи Мадженто поступают), но аккуратно. Да и с выходом 1.5 утечки памяти при импорте-экспорте продуктов решены.
              • НЛО прилетело и опубликовало эту надпись здесь
        –3
        Порадовало, что целых два человека добавили статью в избранное — не уж то на практике будут применять?:)
          +3
          В своё время участвовал в одном «энтерпрайз»-проекте (с очень нехилой для учётных систем загрузкой), всю (по-максимуму) логику (в т.ч. CRUD) делали на хранимках в T-SQL. По-моему достаточно логично. Переносимость — не знаю на сколько она важна, реально в жизни не сталкивался с нужностью перехода с одной СУБД на другую. Единственный заметный минус — дублирование логики, валидации например. А производительность и масштабируемость, на сколько я понял из практики, выигрывает. Так что почему бы аналогично с MySQL не попробовать…
            0
            Боюсь, у всех с опытом разработки от 5 лет есть подобный опыт, в том числе и у меня. Действительно порой оправданно с точки зрения производительности.
              0
              А почему боитесь-то, не понял? Или Вы о переходе на другую СУБД?
                0
                Кроме производительности бывает еще и потребность атомарности в ситуациях вида SELECT + расчёт-на-клиенте + UPDATE/INSERT. Лочить таблицы — херить производительность, а транзакции не спасут из-за неоткатываемости клиентского пересчёта. Вот тогда и выручают stored proc и триггеры.
                +2
                Забыл уточнить, что при этом вне хранимок не было ни строчки SQL-кода (работа с БД происходила исключительно через обращение к хранимым процедурам). Думается мне что это очень неплохо с точки зрения защиты от SQL-иньекций и ошибок строковой логики.
                  0
                  Поделитесь чем профилировали процедуры и делали отладку?
                    0
                    Вы будете смеяться, но таки ничем. Исключительно вручную и на глаз. Если бы знать для этого какие-то удобные инструменты, сэкономили бы уйму времени. Может Вы можете что-то порекомендовать? Сейчас говорят уже вроде в Visual Studio 2010 что-то такое появилось.
                      0
                      (SQL Management Studio / VS) < 2005
                      SQL Profiler, SQL Plan Analizer, ну и есть разные продукты от Red Gate
                    +6
                    неужто ты умудрился из одного слова ТРИ сделать!
                    +2
                    На вопрос «где надо хранить логику данных?» может ответить здравый смысл. Им можно пользоваться не опасаясь, что это «не лучший подход».
                      +6
                      Ребята, а чего вы все такие серьезные? Это топик just-for-fun. Просто мне захотелось проверить, можно ли так сделать. А вы тут действительно развернули холивар на тему «так делать низзя».
                        +9
                        3 комментария — холивар? нюню :)
                        –1
                        Минус который я вижу — непереносимость кода.
                        Приложение привязано в конкретной БД, либо повышается стоимость разработки.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +1
                            >то вы пишите запросы по второму разу и вы не сможете дать гарантию того, что бизнес логика работы БД не нарушена.

                            Во-первых, что значит «бизнес логика работы БД не нарушена». Если хранимок нет — нет и бизнес логики в БД.

                            Во-вторых, для персистентных состояний (если они нужны) существуют транзакции.
                              +8
                              Дорогой друг! Есть прямо противоположная ситуация. Вы, видимо, никогда не меняли свою БД. Представьте ситуацию, когда стоит задача сменить СУБД (смена предпочтений клиента, смена главного архитектора, пожелания «директора», да мало ли ситуаций). В своём случае я использую ORM и модели использующие этот самый ORM. Дык вот я просто сменю бекэнд в ORM-е и продолжу работать как ни в чем не бывало. А что сделаете вы? А если ранее ваши «хранимки» были заточены под Oracle, а теперь нужен MS SQL? А если нужно поддерживать несколько СУБД? А если среди них будет СУБД без «хранимок», а заказчик хочет всенепременно?

                              И да, в моём случае никакого SQL в коде нет вообще, ORM позволяет мне гибко оперировать структурами данных целевого языка, являясь инструментом для создания гибких высокоуровневых моделей. И эти модели даже не заметят смены СУБД.

                              Такой вот не менее поучительный квест.
                                +5
                                видимо в вашем коде не было никогда серьезных отчетов, в любом орм это выливается в здоровенный кусок на чистом SQL, потому как делать такое средствами орм крайне затратно по производительности.

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

                                и даже с орм миграция с одной базы на другую, даже SQL -> SQL, всегда заканчивается полным геморроем (если конечно проект не в 3 строчки и 2 формочки). Это еще тот вопрос что проще смигрировать хранимки или поменять орм адаптер.
                                  0
                                  Был опыт перевода довольно крупного проекта с MS SQL на MySQL. До этого в качестве ORM был Linq2Sql. Купил devart dotConnect, поменял в одном месте дата контекст и коннекшн стринг и всё заработало. Опен-сорс варианты, увы, работали хуже.

                                  А вот для отчётов был другой фронтенд, и там юзались хранимки. А в мускуле синтаксис другой, пришлось попотеть. И, на удивление, жирные запросы работали намноооого медленне MS SQL.
                                    +3
                                    >И, на удивление, жирные запросы работали намноооого медленне MS SQL.
                                    А что, собственно, удивительного? MS SQL, как ни крути, а гораздо более продуманная и производительная СУБД чем MySQL. Ну, может быть последние фишки с HandlerSocket позволяют говорить что MySQL производительнее MS SQL _в отдельных случаях_. Но в целом мускулю и по производительности и по удобству до МСа еще расти и расти.
                                      0
                                      Ну я просто попытался быть вежливым.)
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +1
                                    А давайте «по-менеджерскому» или «аналитически»? Я не конкретизировал языки, а в разных языках ORM-ы некисло отличаются по возможностям и производительности. Я к тому, что оценки разные.

                                    Собственно, давайте оценивать затраты. Что именно переписывать для новой субд? Я вот экспериментировал с тремя, начал с mysql, потом postrgre и ради интереса mssql. Собственно, переписывание заключалось в создании вьюшек и процедур для mssql, и то для эксперимента. В целом же вся система отработала отлично. Но с точки зрения аналитики, затраты на переписывание+отладку всех полностью процедур под новую СУБД сравнимы с затратами на корректировку высокоуровневой модели?

                                    А остальное вполне себе реальность на мелко-средних проектах, но никак не раздувание. Были моменты, когда у заказчика менялись предпочтения, были моменты смены философии у начальства/проектировщиков, по всякому. Но мы же хотим аналитически? Давайте оценим все ситуцации. Для простоты их две. Смена языка: тут вопрос в поддержке нужных функциональностей в ORM-е в нужном языке. Чаще всего базовый функционал таблицы+связи есть везде, вопрос в производительности. Второй момент в смене СУБД. Если уж мы оцениваем аналитически, то в целом ответ очевиден.

                                    А итог очевиден, для каждой ситуации своё решение, о чём я и хотел сказать. В тех ситуациях, когда ТЗ чёткое, заказчик подписался и никто ничего менять не будет ибо документы и прочее, тогда низкоуровневая оптимизация и целевые решения вполне при деле. Но я бы не брал в это дело.нет или яву, они смажут весь эффект от оптимизации. А вот там, где точных целей нет, где всё шатко, а таких проектов подавляющее большинство, где задачи и целим меняются часто (хвала ебучему аджайлу), в этот моменте гибкость ORM-а и модели на его основе отлично прикрывают зад и позволяют спасти время и деньги, потеряв не так много.

                                    Что мне не понравилось выше, так это категоричность, типа «мой мнение завсегда верно». Именно против этого я и выступал в форме равного противоречия.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Ну вообще-то можно использовать и хранимки, и ORM. То есть какую-то специфическую и жутко тормозную выборку засунуть в процедуру, а в ORM дергать метод, который будет это всё возвращать уже в объектах.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            И я так считаю, пожалуй)
                                          0
                                          Когда нужно было сделать третьего клиента к БД, то создал веб-сервис, который работал с БД, а клиенты обращались только к нему :)
                                            +1
                                            Вива! Наконец-то, хоть кто-то вспомнил про трёхуровневую архитектуру! )
                                              0
                                              Это когда производительностью можно в допустимой степени пренебречь. Когда все супер-пупер-критично, то написание процедур оказаться выгоднее (в плане трудозатрат) написания модулей на С-ях.
                                              Но все равно пятерку за паттерн Интерфейс вы получаете )
                                                0
                                                Можно было, хотя сервис был на сях — ничего другого просто не знал практически. А про паттерны тогда и не слышал, преподавали нам процедурное программирование как верх достижения человеческой мысли :)
                                      –2
                                      надо разделять приложение на три части — данные, UI и так называемая «бизнесс-логика».
                                      Эту «бизнесс-логику» реализуем на том же самом php в отдельных классах. И, когда нам понадобятся клиенты на C#, публикуем эти класс в виде (к примеру) web-сервиса и работам только с ними.
                                      Получаем тоже самое, только вместо ХП — методы сервиса.
                                        0
                                        Если думать об этом заранее, то можно написать приложение так, чтобы создание API занимало минут 5.
                                        Не могу сказать как в ZF, а в Rails используя RESTful routes можно уже облегчить себе жизнь, и данные запрашивать в XML/JSON/… Для простых случаев этого более чем достаточно.

                                        XML-RPC/SOAP/… также никто не отменял для более тяжелых случаев.
                                          0
                                          Поверьте пользовался, но это был большой корпоративный интранет проект java + oracle.
                                          О другой БД речи не шло.

                                          В webdev все несколько иначе. Есть проект php/perl/ruby/python + mysql. В некоторый момент при превышении нагрузки необходимо перейти на тот же postgresql.
                                          Вот тут action record решения и являются наиболее гибкими.
                                        0
                                        Пробовал когда-то (не для веба) — отпугнуло неудобство разработки хранимок и ограниченный функционал (сейчас может поменялось, но тогда не нашёл способа динамически менять имя таблицы в запросе).
                                          +3
                                          Ещё подкину пару минусов хранения большей часть логики в БД:
                                          1. базу обычно стараются разгрузить, потому что добавить ещё ноду с базой на порядок сложнее, чем ноду с веб-аппликейшном
                                          2. работа в команде с базой таки почти не прёт
                                          3. очень трудным становится сделать так, чтобы одна нода продакшена работала на новой версии логики какое-то время (чтобы проверить её)
                                            +7
                                            1. Правильно написанные хранимые процедуры способны разгрузить базу (не забываем про навороченный оптимизатор SQL-запросов в любой субд)
                                            2. Да, но сколько ж вы туда собираетесь загнать кода, что вам нужна команда DBA?
                                            3. Проверять логику на продакшене? Хм…

                                            Есть у такого подхода один убойный плюс, про который все почему-то забыли. Это безопасность. Можно закрыть доступ к обычным селектам-апдейтам и делать все через хранимые процедуры. Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.
                                            Это почти стандарт при разработке например банковских систем.
                                              0
                                              Я написал — бОльшую часть логики. Понятно, что надо знать меру и в том, и в другом подходе. Всё выносить из базы в код тоже нельзя (я тоже против этого), но и морфологичеикий анализ в базе делать — это извращение. Я вот о чём хотел сказать.
                                                0
                                                1.А неправильно написанные способны ложить базу
                                                2.Базу действительно лучше писать одному ИМХО.

                                                Хранимые процедуры имеют мало общего с бизнес-логикой. С нормальной бизнес-логикой. Разумеется почти всё можно сделать на SP и T-SQL но это такой тупиковый геморой. Особенно быстро это становится понятным при работе с несколькими базами, при репликациях и т д.

                                                А безопасность да.
                                                  0
                                                  1. Не аргумент — для этого есть тестирование.
                                                  2. На примере Oracle — действительно крупную задачу удобно разбить на части и реализовывать в разных пакетах (например) разными разработчиками. И да, есть варианты реализации в БД вышеупомянутых «крупных задач».

                                                  В остальном да, идея не новая, спорная, но… вариант :)
                                                  0
                                                  Если мальчиш-плохиш вдруг сопрет пароль от базы, не зная процедур — он не сможет сделать ничего. И в любом случае не сможет слить базу.

                                                  Что ему помешает вызывать процедуры? Через процедуры слить нужную инфу? Чучка больше времени?
                                                  Это почти стандарт при разработке например банковских систем.

                                                  нема такого стандарта, не почти, никак.
                                                    +1
                                                    Эээ, что, простите? У вас нема такого стандарта? Э…
                                                    Вот представьте себе таблицу «юзеры». Пароль SQL-суперадмина от «боевой» бд есть только у сурового начальника службы безопасности. Заводить и редактировать юзеров может только он (ну ок, «мальчик» от его имени).
                                                    У обычных клиентов (читай программистов банковского приложения) есть только очень усеченная в правах учетная запись. Без права выполнять селекты, инсерты или апдейты на таблице юзеров. Есть только доступ к одной хранимой процедуре, которая по паре параметров (логин, хэш пароля) либо возвращает 1 строку с профилем текущего пользователя, либо — если логин или хэш пароля не верны — возвращает ноль строк.
                                                    Ну вперед, слейте в таком конфиге таблицу «юзеры». Или хотя бы пары «логин — хэш пароля».
                                                +4
                                                У нас есть довольно крупный проект, написанный на MSSQL/.Net/XSLT в котором используется как раз такой подход. Вообще да, это работает, но у подхода довольно много недостатков, например сложнее горизонтально масштабировать, ошибки в коде хранимок часто невозможно отследить в силу того, что код не компилируется, я уже молчу про юнит-тесты для этого добра.
                                                П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
                                                  0
                                                  Проблемы, описанные Вами, существуют для более ранних технологий MS.
                                                  1. Сейчас есть возможность писать хранимки на c#. Соответственно, Вы можете в них прописывать соединение к внешнему SQL серверу. И, таким образом, производить горизонтальное масштабирование. Попутно к этому можно много на дублирующем сервере привязать.

                                                  2. Сейчас хранимки пошагово отлаживаются. В т.ч. на tsql.

                                                  Попробуйте MS SQL 2008 + Visual Studio 2010. Проект типа database и вперёд. Это неимоверное удовольствие.
                                                    0
                                                    Я про все это прекрасно знаю.
                                                    1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
                                                    2. Знаю. Помогает не сильно.
                                                    Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
                                                    Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
                                                      0
                                                      Ну я в принципе предполагал, что увлечённый человек это попробовал. =)

                                                      Тогда, если не возражаете, я хотел бы Вас немного помучить.
                                                      1. Если сравнить 2-х звенку с логикой в БД и 3-хзвенку (web не рассматриваем, т.к. другие случаи). То неужто (по Вашему мнению) геморней писать логику в БД, чем пилить трёхзвенку? Тут же и частей больше, и удобства при программировании меньше и т.д.
                                                      2. А вообще апдейты и поддержка клиентов при логике в БД насколько проблемны? Потому что код поменять — это dll переподключить новую. Но если ещё структура меняется, да если ещё пользователи работают. По горячему (когда пользователи работают) вообще это возможно делать?
                                                      3. Коллективная разработка в случае логики в БД насколько проблемна? Какие основные проблемы?

                                                      Спасибо.
                                                        0
                                                        1. В случае с 2-х звенкой у вас в БД просто неявно будет спрятано два уровня — логики и доступа к данным. В противном случае очень сложно, а то и вовсе невозможно будет организовать юнит-тесты бизнес-логики, а без них жить очень сложно. Соответственно, в общем случае нет никакой разницы, где находится логика — на сервере БД или на middle-tier сервере, а так как последний проще масштабируется, то выбор очевиден. Конечно, если приложение небольшое и развивать его не планируют, то 2-х звенка банально дешевле, поэтому стоит выбирать ее. В таком случае 3-х звенка это как использовать паттерн MVC для домашней странички с фотографией кота — профита никакого, а затраты непропорционально огромны, лучше написать простейший скрипт на РНР. Но если ваш проект куда больших масштабов то нужны другие подходы.

                                                        2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
                                                        Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).

                                                        3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.

                                                        В общем, по моему личному мнению, чем больше вы отвязываетесь от БД, тем легче вам жить. Но это мнение основано на моем опыте разработки довольно специфического корпоративного софта.
                                                  +2
                                                  Рискну выразить свое мнение.

                                                  Тот кто не работал с SQL — системами у которых бизнес — логика размещена на сервере, даже не представляют насколько это ОБАЛДЕННАЯ вещь!
                                                  2 сек. и все работают по новым правилам!

                                                  Естественно что ресурс SQL — Server (это проблема кластера..) пожирается с огромной скоростью (но это зависит уже от реализации), но с точки зрения поддержки бизнес-систем это еще раз ОБАЛДЕННЫЕ условия работы!

                                                  Не нужно так строго и однозначно говорить «бизнес-логика на SQL» — это плохо…

                                                  Видел я «популярные» бизнес-системы, в которых на производстве пользователей выбивали из сессий по графику…

                                                  Для работы в WEB — оценить не могу… слаб я в этом вопросе.

                                                    –1
                                                    Добавлю:
                                                    нужно очень хорошо заранее продумать и построить систему.
                                                    Но это действительно сложно. :(
                                                    и не на уровне ЦПШ это делается

                                                    :) ЦПШ — это не Центральная Партийная школа КПСС
                                                    а Церковно — приходская школа…
                                                    это приходит потом… в зависимости от понимания МИРОВЫХ ТЕНДЕНЦИЙ РАЗВИТИЯ

                                                    Sorry… если кого — то обидел.
                                                      –1
                                                      Ой.
                                                      Еще уточнение…

                                                      ЦПШ = ХТМЛ + ПХП + JS
                                                      0
                                                      ааааааааааа маньяки на Хабре… :)
                                                        +1
                                                        Это вы об Ильиче? ;)
                                                        +8
                                                        Где-то встречался с аргументом в пользу такого подхода применительно к Oracle: сколько веб-технологий сменилось за время существования PL/SQL? Да он существовал все то время, что вообще существует веб. Технологии постоянно меняются, а PL/SQL лишь расширяется и весь старый код более-менее работает. Люди городят хитрые абстракции для доступа к БД на случай ее смены, но гораздо чаще меняется не БД, а сама веб-технология.

                                                        На самом деле хранить логику в базе довольно удобно (по крайней мере в случае с Oracle). То что делается на middle tier достаточно объемным кодом, на PL/SQL зачастую делается парой строк, а работает быстрее и надежнее, ведь данные не нужно никуда гонять и с транзакциями проще.

                                                        Проблемы действительно начинаются на больших проектах из-за сложностей с управлением версиями, тестированием и, конечно, масштабированием. Но для небольших проектов хранить логику в хорошей СУБД — это незаслуженно непопулярный подход. Вполне можно им пользоваться.
                                                          +1
                                                          небольшие проекты не в состоянии пользоваться дарами Oracle (не по карману точнее), это удел больших интерпрайзов.
                                                            0
                                                            Есть такое дело, но я подозреваю что в других СУБД с этим сейчас уже тоже получше стало. Просто не писал под них в этом стиле, поэтому делюсь тем, с чем работал.
                                                              +5
                                                              Небольшие проекты пользуются дарами postgresql.
                                                                0
                                                                А кроме Oracle других SQL — нет?

                                                                MS SQL Express разных версий…
                                                                сейчас там ограничения вполне достойные…
                                                                даже для реальной жизни их хватает… И ресурсы не очень большие…
                                                                  0
                                                                  а oracle xe уже не торт? ;-)
                                                                    0
                                                                    когда проект один — вполне торт

                                                                    а если вы захотите захостить несколько небольших проектов на одной машине (вполне естественное желание) — то сразу же не торт
                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                      0
                                                                      И он замечательно отлаживается пошагово в IBExpert, например.
                                                                        0
                                                                        Я всецело поддерживаю FB, но пошаговая отладка процедур в IBE — это миф. Сам FB такую фичу не поддерживает, а то что есть в IBE — это эмуляция, и она не всегда работает так как надо. Эта тема с завидной регулярностью поднимается на sql.ru
                                                                          0
                                                                          Почему миф, если работает? Пошаговая отладка вообще мало где работает, как надо. Меня то, что делает IBE, устраивало на 100%.
                                                                          Но в любом случае, спасибо за инфу. Даже не догадывался, что это эмуляция.
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                      0
                                                                      Но писать большие куски кода на PL/SQL — это сильная боль в седалище… Наверное, это вопрос компромиссов…
                                                                        +2
                                                                        Скорее вопрос привычки. Сам PL/SQL не так уж и плох. Та же интеграция SQL'а очень удобна. Но да, он отличается от того на чем обычно программируют сегодня и требует определенной перестройки. Например почти полного отказа от ООП, ибо там с ним плохо, да и не удобна работа с данными в ООП без ORM. Но если подумать, то в бизнес-задачах возможности ООП вообще мало где используются сегодня. В основном классы являются просто структурными единицами, с чем вполне могут справиться и пакеты. Есть конечно любители rich-моделей (я и сам в их числе), но это не мейнстрим. Практически любой современный фреймвок вынуждает отказаться от развитого объектного проектирования и остановиться на какой-то не совсем логичной и совсем не компактной, но зато стандартной структуре.

                                                                        В общем, если не относится к PL/SQL как к злу, а воспринять это как возможность поработать в другом стиле, то он не особо раздражает. Раздражает только отсутствие человечных IDE. При всей строгости PL/SQL'я IDE могла бы делать там очень много всего, но не делает или делает не удобно.
                                                                          0
                                                                          А как же стандартные IDE для оракла — TOAD, SQL Navigator, PL/SQL developer и SQL Developer?

                                                                          Там даже дебаггинг есть, и SVN прикручен к SQL Developer.
                                                                            0
                                                                            Не удобные и туговатые они по сравнению с хорошими IDE для Java, например.
                                                                              +1
                                                                              Есть такое, особенно оракловый SQL Developer. А вот PL/SQL developer достаточно шустрый, что особенно в нем нравится — автоматическое создание новых коннектов к базе для нового окна. Не нравится — не может делать одновременных коннектов к разным базам.

                                                                              Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
                                                                                +1
                                                                                На самом деле в любой приличной Java IDE штатно или через плагины можно выполнять запросы и смотреть результаты. Естественно, это далеко не основная фича, поэтому она обычно реализована довольно примитивно.

                                                                                Но в целом дело вряд ли в памяти, потому что у тех же Java IDE, например, создается и поддерживается гигантский индекс для code completition по всем пакетам, классам, методам, полям, переменным, xml'кам etc. Причем он строится и по коду который пишется вот прямо сейчас и может быть вообще не валидным. Разработчики всех этих IDE потратили уже столько сил на эту фичу, что она реально работает настолько круто и удобно, что писать без нее или с каким-то примитивным комплетишеном вроде того, что можно встретить в каком-нибудь TOAD'е, как-то не комфортно.

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

                                                                                Я не думаю что редакторы PL/SQL или другого языка хранимых процедур когда-нибудь дойдут до чего-то подобного — просто слишком маленький рынок. Как и для Scala, к примеру, которая мне очень нравится, но писать на ней я не могу, ибо при всей ее выразительности на Java выходит быстрее. Потому что для нее есть хорошие IDE, а для Scala пока только ущербные плагины к ним.
                                                                                  0
                                                                                  Согласен с вами. Спасибо за комментарий, с Java IDE дел не имел, было полезно узнать.
                                                                              +1
                                                                              Одно уточнение — отладка есть не в IDE, а в самом Oracle (DBMS_DEBUG). В IDE просто интерфейс к нему.
                                                                                0
                                                                                Истину глаголите!
                                                                              +1
                                                                              Не знаю, может я такой привередливый, но мне много всего не хватает в PL/SQL. Не хватает элементарных структур данных (нормальных, а не прикоцаных коллекций), не хватает механизмов манипуляции этими данными.

                                                                              А некоторые «приёмы» заставляют меня вспомнить о залихватском сишно-ассемблерном детстве:

                                                                              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 :)
                                                                                0
                                                                                Думаю, в любом языке найдется что-то, от чего хочется биться головой об стену. Мир не идеален, вместе с PL/SQL :)
                                                                          0
                                                                          Интересны похожие статьи про разработку на Python&Postgres (для использования на практике). С MySQL такого делать не хочется…
                                                                            0
                                                                            Для одного проекта, делал похожую реализацию для бэкенда, но и то — использовал Postgres.
                                                                            Возможно, что для некоторых задач — такой подход оптимален.
                                                                            Но в большинстве случаев — проще использовать более привычные/традиционные технологии. Особенно, когда в разработке/поддержке принимают участие несколько человек.
                                                                              +3
                                                                              У нас на Oracle пара совсем не маленьких проектов так и сделаны.
                                                                              Очень удобно — клиенты на Java, Delphi и Web. Отладка по шагам присутствует.
                                                                              Всем нравится, все довольны.
                                                                              Но не буду утверждать, что так надо делать всегда.
                                                                                0
                                                                                Какая у Вас версия Oracle? У нас до 10.2.1.5 (дай бог памяти, вроде так) дебаггер PL/SQL мерзенько вис по любому поводу…
                                                                              0
                                                                              На самом деле не ново. Работал в компании. Там все было подвешено на Oracle. Как факт она была необходима. Так вот для вывода всей аналитики, статистики и т.д. был разработан похожий фреймворк. Он даже код генерировал сам. Не MVC конечно. Но использовать было на самом деле удобно. Учитывая, что разработка и логики и интерфейса была на одном языке. Это конечно не супербонус, но затея имеет право на жизнь.
                                                                                0
                                                                                Я и не говорил, что это ново. Я ссылаюсь в тексте статьи на проект, в котором был применен подобный подход еще в 2006 году. Тогда у меня и родилась идея опробовать данный подход на MySQL с его несравненно более обрезанными возможностями по реализации хранимых процедур. Просто руки до этого дошли только сейчас.
                                                                                  0
                                                                                  я скорее про новизну в ответ на комменты сказал)
                                                                                +2
                                                                                Делал как-то с товарищем один модуль к проекту. Так вот там такой подход (перенос логики в БД) оказался выгодным — он быстрее работал.
                                                                                  0
                                                                                  за счет того, что встроенные процедуры не требуют постоянно соединяться, аутентифицироваться итд. они работают с правами самой базы.
                                                                                  –6
                                                                                  О фактическом исполнении описанном в топике — я не говорю, возможно это для кого — то толчёк.

                                                                                  Речь идет о самой идее «Логика — это проблема сервера» ????

                                                                                  Ответ в комментариях стартера «Ребята, а чего вы все такие серьезные? Это топик just-for-fun.»
                                                                                  извините… отстой. А зачем тогда поднимать тему?

                                                                                  Я принимаю тему как вопрос «Есть ли жизнь на Марсе ?»

                                                                                  Мой ответ: Да, есть.
                                                                                  Вопрос ее реализации.

                                                                                  Если вы планируете построить долгоживущую и позволяющую дальше развиваться
                                                                                  систему — то у вас при использовании логики на серверной стороне — ЕСТЬ ПЕРСПЕКТИВЫ
                                                                                  железо развивается намного быстрее ПО ( пока ), есть много разных способов…

                                                                                  Если вы хотите всю логику своей системы положить на клиента — да у вас есть фора… несколько месяцев
                                                                                  (или небольшое количество лет)

                                                                                  В идеале ( утрирую естественно… )
                                                                                  у меня есть телефон!
                                                                                  я все свои обязанности по могу выполнить через него!
                                                                                  ( к грузчикам это не относится )

                                                                                  Мы говорим о том, что ИТ может дать менеджерам, независимо то того какого уровня эти менеджеры.
                                                                                  а по жизни… мы на них работаем ( нагружаем «лишними» галочками конечного пользователя, чтобы потом дать манаГерам красивые отчеты, которые они нам готовы оплачивать… и т. д.

                                                                                  и в конце концов ( некоторые) — дают понять что кто-то или что-то мешает данной компании.
                                                                                  Это идеал…

                                                                                  а на самом деле и сейчас и всегда — информация -это повод для размышления.
                                                                                  Мы со своей стороны даем информацию для принятия решения…
                                                                                  ааааааааааааааааА на ТОЙ стороне сидит ДЕБ*Л
                                                                                  и что вы можете сделать?

                                                                                  Не переоценивайте свои возможности.

                                                                                  ИТ, по сути — всегда на тонну стали ( молока, сала, или молока )

                                                                                    +4
                                                                                    Картинка «комментарии пьяным не писать».
                                                                                    –1
                                                                                    Однако сия замечательная функция не работает применительно к MySQL. Потому...

                                                                                    надо было оставить MySQL. Не для этого она.

                                                                                    PS
                                                                                    данный подход имеет место для систем со сложной БД и логикой, особенно когда с БД работает более одного приложения. в данном случае, наличие единого согласованного api на уровне субд это плюс.
                                                                                      +2
                                                                                      В книжках по СУБД и БД написано на первой странице — база должна быть настолько простой насколько это возможно.
                                                                                      На личном опыте убедился что перенос бизнес-логики в базу это зло. Такой подход возможен но он учит ездить задом наперёд. Это не верно даже с точки зрения хороших манер.

                                                                                      Вопрос — кто-нибудь реально сталкивался с необходимостю смены платформы или базы данных? Удалось ли это сделат «щёлкнув пальцами» даже при наличие всех грамотных слоёв приложения и отряда хранимых процедур в базе?

                                                                                        0
                                                                                        За несколько лет веб-разработки сталкивался всего однажды, совсем недавно. Проект на python (Django) переезжал на моих плечах с PostgreSQL на MySQL. ORM справился со всеми запросами, кроме одного — была какая-то выборка наискосок по всей базе данных, которая причудливо сломалась.
                                                                                          0
                                                                                          Большой проект?
                                                                                            0
                                                                                            Ну сравнительно приличный, социальная сеть для веб-мастеров со всякими сопутствующими плюшками, и биллинг.
                                                                                          0
                                                                                          Есть два момента. Смотря для чего, как говорится. Для высоконагруженных систем никто не решится это делать, в частности большинство грандов вообще ушли к NoSQL базам, я логика-то вся ясное дело в коде. А вот для «обычных» приложений вполне можно. Всё зависит от ситуации, не нужно просто критично подходить. В статье описан просто способ, не более того. Жаль, без сопроводительных советов «где применять, а где нет». Самое главное, что у всего (вообще всего) есть плюсы и минусы.

                                                                                          Ответ на ваш вопрос: сталкиваются люди и регулярно. И, по уму, такое столкновение должно быть заложено в любой проект помноженное на вероятность/риск.
                                                                                            0
                                                                                            То что «люди сталкиваются» это понятно по кругам на воде. Но я лично не встречал людей которые в здравом уме и ясной памяти «портируют» живую базу с одной СУБД на другую.
                                                                                            Ещё понятно если десяток таблиц. Но если это реальный монстр стянутый отношениями как паутина плюс сотен пять процедур… Мне кажется это выдавание желаемого за действительное. Всё равно прийдётся вручную всё проверять. Это если какая-нибудь база данных сайта. А если банка? Или железнодорожного узла управления.

                                                                                            Я бы не рискнул писать серъёзное приложение которое предполагало бы смену платформ или СУБД.
                                                                                              0
                                                                                              Никто не горит особенным желанием мигрировать с одной СУБД на другую, это уж точно.
                                                                                          0
                                                                                          При таком подходе что будет со скоростью отработки скриптов? Вы делали какие-либо бенчмарки?
                                                                                          Насколько мне известно использвание хранимых процедур в MySQL несколько негативно сказывается на производительности системы, чем если бы использовались простые select-ы, insert-ы и т.п.
                                                                                            0
                                                                                            Дети, не делайте так. Работать будет и вы даже сможете написать работающее приложение. Но вы потратите время на изучение тупикового пути.
                                                                                            Делайте как написано в книжках — простая база, слой видов и хранимых процедур в базе, слой доступа к данным в приложении, слой бизнес-логики в приложении, слой отображения.

                                                                                            Эти правила как и правила дорожного движения написаны кровью!
                                                                                              0
                                                                                              Биллинговые системы у Опсосов, крутящиеся на Оракле, всю логику имеют в базе — куча пакетов, процедур и функций, зачастую заврапленные с непонятными наименованиями вида kk_576_ml и т.д. Сотни пакетов и продур, тысячи таблиц, миллионы строк кода.

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

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

                                                                                                Второй проект — небольшое веб-приложение. Вся логика — в БД (для сравнения, кода на Джаве — 50к строк, кода на PL/SQL — 25к). Из очевидных минусов — геморройность при отладке, завязка на одного человека (DBA).
                                                                                                  0
                                                                                                  Те, кто вопит о том, что логика в БД — зло просто никогда не делал проектов со сложной логикой. Логика в БД удобна в первую очередь тем, что абсолютно не привязана к клиенту.
                                                                                                    0
                                                                                                    Трехзвенная архитектура, а не клиент-сервер позволяет решить проблему разных клиентов.
                                                                                                    0
                                                                                                    А меня больше всего заинтересовало, как вы сделали инициализацию приложения Zend Framework из командной строки — расскажите?

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

                                                                                                  Самое читаемое