Покритикуйте подход?

Question

[Сергей Савостин]

Есть идея создать web-приложение, не суть важно какое, где вся логика работы с данными (API, Restful, CRUD) не будет вынесена за пределы базы данных. Т.е. всю бизнес-логику оставляем внутри базы, пишем на innoDB-триггерах, SQL-процедурах и SQL-функциях. PHP (допустим) не делает никаких SELECT/INSERT/UPDATE/DELETE, а вызывает только процедуры типа METHOD_acion(params).
Например, GET_some(id);
Из плюсов вижу:

1. Данные и логика в одном месте
   
2. PHP легко заменяется на всё, что угодно, вплоть до nginx модуля на С
   
3. Версионность, целостность кода+данных легче (?) контролировать
   
4. Бэкап одним дампом
   

Из минусов:

1. Как работать со "сложными" данными/параметрами, в частности с JSON? Есть ли какой-то "универсальный" формат передачи иерархических данных PHP <-> MySQL? На случай, если понадобится отдать xml, например.
   
2. К предыдущему пункту: валидация входных данных - как?
   
3. Как все-таки сделать версионность?
   
4. Отладка кода - мрак еще тот.
   
5. Удобства почти ноль - ни фреймворков, ни библиотек - все ручками.
   

Кто-то таким извращением занимался? Отговорите меня ;)

Comments

[napa3um]

Вы все минусы сами описали. Но, видимо, не очень их осознали, раз считаете, что после их формулирования имеет смысл продолжать искать ответ на свой вопрос :).

[Сергей Савостин]

napa3um: Ну, ручками писать мне даже приятнее. Отладка тоже не пугает. А вот с данными может я чего-то и не знаю...

[napa3um]

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

Answer 1

[lega]

Отлаживал я один такой проект одной крупной (forbes top 40) компании, тот ещё отстой, тормозило как в не себя, хранимые процедуры в 10к строк.

- Ну удобно разрабатывать
- Язык не для разработки приложений (если это *SQL)
- Будет больше тормозить, т.к. вся нагрузка идет на одно звено, когда в высоконагруженых проектах стараются наоборот, разгрузить центральные звенья.

Comments

[Сергей Савостин]

Спасибо.

Answer 2

[Night]

Тестировать адски сложно. Сложно приделать авто-тесты (модульные и другие), да и вообще, выносить логику приложения в БД - плохая идея.

Answer 3

[Yustas Alexu]

Возможна такая ситуация: где-то что-то поменял и все рухнуло. А где и что поменял, не помню.

Comments

[Сергей Савостин]

А с php не так разве?

[Yustas Alexu]

Сергей Савостин: Код PHP это текстовые файлы, которые можно засунуть в гит. Если что-то рухнет, лезем в гит и смотрим, какие были последние изменения и где. А если это какие-нибудь триггеры в базе данных, то надо сравнивать с предыдущим бэкапом, который может быть неделю назад делался.

[Сергей Савостин]

Yustas Alexu: ну, для этого все изменения делаются на dev сервере, а боевой обновляется после commit дампа с dev-сервера... Впрочем, как и php :)

[DevMan]

Сергей Савостин: разница в:
- с php знакомо гораздо больше людей
- php лучше версионируется
в остальном читайте мой ответ.

Answer 4

[Dmitry BPW]

Поддерживаю Night. Очень сложно тестировать подобные вещи. А без надлежащих тестов не получится качественного продукта. Как вариант, можно оставить идею, но немного смягчить её. То есть вынести за пределы БД хотя бы часть запланированного. Тогда и тестить легче, и тормозов тоже меньше.