| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Хранимые MySQL процедуры |
| Автор: BuShaRt 6.6.2012, 10:19 |
| Забегу вперед и сразу отвечу на вопрос, почему этот топик я создал в этой ветке. Суть вопрос не в технической реализации хранимых процедур, а в том, как это отражается на архитектуре приложения, которая прежде по большей части строилась на базе PHP. К сути. Руководитель в текущем проекте настаивает на полной инкапсуляции всей логики работы с БД в хранимые процедуры MySQL. Меня, как разработчика, такая идея очень удивила. Я уже давно свыкся с мыслью, что ведущие разработчики всего мира являются приверженцами объектно-ориентированного подхода к программированию. Благодаря этому движению мы имеем паттерна ActiveRecord и проекторы, вроде Doctrine, которые по сути призваны реляционную логику приводить к объектно ориентированной. На фоне этого использование хранимых процедур мне кажется возвратом в каменный век. Т.е. имхо с точки зрения удобства в работе - это просто катастрофа. Далее я пытался найти другие, возможные плюсы, этого подхода. Единственный более или менее достойный ответ был - это безопасность. Я соглашусь с тем, что безопасность действительно выше, но сомневаюсь, что прирост общего показателя безопасности будет существенным. Так вот у меня вопрос. Какой смысл от этого подхода? |
| Автор: MoLeX 6.6.2012, 11:21 | ||
В чем? После взлома сайта могут залить тот же пыхадмин и получить данные из СУБД, в том числе и хранимые процедуры (а из них вывести опять все связи). |
| Автор: BuShaRt 6.6.2012, 12:25 |
| MoLeX, Предполагается, что приложение не может выполнять произвольные запросы - только процедуры. |
| Автор: ksnk 6.6.2012, 12:50 | ||
Кто ограничивает приложение? Внутренняя самодисциплина разработчиков? Или есть более другие способы запретить выполнение любого запроса? |
| Автор: BuShaRt 6.6.2012, 13:21 | ||
Для работы с базой данных приложение использует определенную учетную запись, закрепленную за ним. У этой учетной записи права минимальные т.е. только запуск процедур. Добавлено через 4 минуты и 48 секунд Просьба не уходить от основной темы топика - хранимых процедур. Вопрос безопасности - это частность, а меня интересует ваше общие мнение о данной технологии. |
| Автор: MoLeX 6.6.2012, 13:51 | ||
правила форума запрещают использовать всю мощь русского языка, если вкратце: да ну её нафиг |
| Автор: Fortop 6.6.2012, 14:21 |
| Смысл в отделении логики приложения от различных фронтендов. php и web-интерфейс это не единственные потребители БД. |
| Автор: BuShaRt 6.6.2012, 15:34 | ||
А если единственные? |
| Автор: ksnk 6.6.2012, 16:52 | ||
Весь проект самодельный и переписывать - добивать его будет одна и та же команда разработчиков? Следует понимать, что ни один сторонний модуль подключить не удастся. Придется самим писать все служебные утилиты навроде phpmyadmin. Ну или запускать такие утилиты под более правильным аккаунтом. |
| Автор: JackGmen 6.6.2012, 17:56 |
| Я думаю этот вопрос стоит задать руководителю ... |
| Автор: Fortop 6.6.2012, 18:10 | ||||||
А без "если". Оценочный размер проекта в человеко-часах. Круг задач, которые он должен решить. Доступные ресурсы Этот тот минимум, чтобы можно было хотя бы гадать на кофейной гуще. Добавлено через 1 минуту и 13 секунд
Это о чем? Какой сторонний модуль?
Разве это проблема? |
| Автор: Sanchezzz 6.6.2012, 18:45 |
| Хранимые процедуры лучше использовать в триггерах когда происходят какие то события с таблицами но не более, переносить логику в БД это тупость. |
| Автор: BuShaRt 6.6.2012, 23:48 | ||||
| Fortop, Кратко. Проект рассчитан на 2 месяца, задача/цель - каталог с возможность заказа (без оплаты) со сложным механизмом фильтров и выгрузкой данных в CRM, ресурсы в разумных пределах не ограниченные. Архитектура проекта целостная и предполагает только выгрузку данных по собственной инициативе. Т.е. единственный потребитель базы данных - само приложение, оно же и занимается выгрузкой данных. Не каких сторонних потрибителей, согласно спецификации, в проекте не придусмотренно.
Руководитель ответил, что так мы избавляемся от необходимости писать SQL в коде и улучшаем безопасность. Более подробных комментариев получить не удалось.
Не знаю, что именно имел ввиду ksnk, но меня ооочень сильно напрягает невозможность работать с базой через ORM. |
| Автор: ksnk 7.6.2012, 00:18 | ||
Систему комментариев на сайте, почтовые рассылки, служба online-саппорта и так далее - все это придется не брать готовыми из готовых проектов а писать самим практически с нуля... Если сверхзадача - написать все самим и самим же это все тащить, развивать и поддерживать, то почему бы и нет, но скорее всего задача - получить работоспособный, расширяемый проект |
| Автор: BuShaRt 7.6.2012, 09:51 | ||
Таких модулей в проекте не придусмотренно =) Все сами... ну или за счет более мелких составляющих.. |
| Автор: ksnk 7.6.2012, 09:55 | ||||||
Это точно система online-заказов?  |
| Автор: Fortop 7.6.2012, 13:27 | ||||
И каким образом это связано с проектом и его базовой логикой? Отдельные подсистемы поддержки, интеграция в проектом не будет слишком уж сложной.
Не вижу сложной логики и соответственно каких-то особенных требований. Но, возможно, процесс заказа у вас достаточно сложен и многоступенчат (что маловероятно). В остальном... смысл небольшой есть, если у вас есть хороший DBA. Если все пишет один человек - смысла 0. |
| Автор: ksnk 7.6.2012, 14:40 | ||||
C базовой логикой - никак не связано, а вот с потребностями по расширению проекта, которые придут в голову сразу после успешного запуска - связаны.
посмотри на http://www.ulmart.ru/ - как бы тоже каталог, без оплаты, со сложным механизмом фильтров. |
| Автор: Sentox 7.6.2012, 22:41 | ||
| Я так понимаю в хранимых процедурах будет не бизнес - логика, а логика табличного шлюза к данным. Но здесь две проблемы и одна из них довольно острая, как сказал ksnk,
100% Жёсткая привязка к типу БД, да и к свойствам таблиц и их полям. И так же не самая последняя проблема, это так сказать "улучшения" в версиях БД могут стать проблемой на пути перехода на версию выше, так как частенько эти "улучшения" становятся не совместимыми, что соответсвенно сокращает список версий БД для использования приложением. |
| Автор: Sentox 7.6.2012, 22:59 |
| Я бы порекомендовал бы всё равно вызов процедур вынести в отдельный класс шлюза к БД на той же платформе что и само приложение. Это бы дало лучшую гибкость вслучае, если всё таки проект будет расширяться, так как в методах такого класа можно без труда изменить логику доступа к БД, не затрагивая клиентского кода. (впринципе может Вы так и сделали  ) |
| Автор: Fortop 7.6.2012, 23:29 | ||||
Это не имеет значения для продукта внутреннего пользования
И где там сложная логика работы с БД Идиотский и перегруженный интерфейс вижу. Но и не более того |
| Автор: ksnk 8.6.2012, 07:31 | ||
Это просто пример развития "каталога без оплаты". А сложность и в facebook'е нету. Все просто |
