Вывод значения radio или помощь в переделывании кода

серьезно?
разводим логику на разные уровни?
я был лучшего мнения о тебе
по поводу укора толстых ормов
согласен
но!!!!
они на своем месте
не всегда(далеко не всегда) во главу угла становится производительность
юзабильность кода в самом начале
потом можно подменить слой тупо фасадами
но нужен agile
(Добавление)
сам сейчас пишу решение для утоньшения моделей но с возможностью гибкости запросов
сам понимаю что орм уж слишком зауниверсалили и усложнили
надеюсь получится
только вот смену хранилища сложно сделать
может и не получится

Серьёзно. Зачем на разных? Вся бизнес-логика в хранимках.
Вполне приятный в работе подход. Строгая типизация, полная транзакционность обработки без каких-то оговорок, для PHP нужны гранты только на запуск хранимок, даже select не нужен.

-----
PostgreSQL DBA

интересно
а как насчет смены хранилища?
забиваем и уверены что всегда постгресс?
(Добавление)
всем новичкам говорим что мало код прочитать...надо еще в субд полазить
да?
имхо не лучший подход но готов выслушать
готов изменить мнение
(Добавление)
Мелкий до оптимизации еще добежать надо уметь
оптимизировать может любой дурак который про btree прочитал
а попробуй распределить ресурсы...вот где начинается кровавый интерпрайз
вот где мне страшно становится

Ну-ка честно, сколько раз за время жизни проекта нужно менять персистентный сторадж?
Один раз в десять лет? Ещё реже?

Смотрим правде в глаза: уже лет через 5-7 проект всё равно или сдохнет сам или его надо будет капитально рефакторить или сразу переписывать.
Ну и какой смысл тратить кучу сил на фичу, которая никогда не понадобится?
Такое же архитектурное решение, как и прочие "возьмём фреймворк Х". Можно на уже написанном приложении поменять фреймворк? Да, можно. Вот только даже не знаю, что проще - сменить фреймворк или смигрировать хранимую логику в другую базу.
(Добавление)

А что изменилось?
В СУБД надо полазить всегда, знать что где лежит, в каком формате и где какие аггрегаты лежат. Всё то же самое, ничего не поменялось.


Ну и в топку его. Там скучно.
Ресурсы какие именно?

-----
PostgreSQL DBA

Мелкий менял сторадж 3 раза в год
был проект
не вру
и дело совсем не в этом
если не менять сторадж то можно вообще в модели писать запросы(ой .... или ты об этом)
ыыыы...тогда просто умолкаю
тогда вообще пишем все на асемблере
Мелкий короче не убедил
уважаю тебя как спеца но не убедил

А зачем? Мне любопытно стало.

-----
PostgreSQL DBA

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

У меня-то ЛС работает, не далее как сегодня вот на тебя же получал абузу.


Почему?
Был у нас джун, никаких проблем с хранимками. Да и у меня никаких проблем. На тот момент у меня было два месяца работы с pg и фактически ноль в pl/pgsql.


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

Кто-то, начитавшись всяких твиттеров и лицокниг, считает, что РСУБД годится только как key-value хранилище и не дай ктулху сделать что-то более сложное чем выборку по первичному ключу. range-запрос? join? Ужас в глазах и флакончик с корвалолом.
Мы наоборот любим над базой издеваться, и, что странно, база отлично работает.
Где-то понадобится изучать новый фреймворк (и повезёт, если что-то вменяемое, широко известное и адекватное, а не nette всякие)
Где-то вместо толстых моделей - тонкие и логика данных в контроллере.
Какие-то человечки считают, что контроллер может обращаться только к одной модели.
Где-то считают, что вьюха может сама обратиться к модели, где-то - нет.
А где-то и другой язык понадобится - nodejs или golang какой-нибудь.

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

-----
PostgreSQL DBA

реализовал в редисе сортировку по весам с дробями
обошелся без карвалола
но...чем нагляднее тем лучше
разовый опыт
чем нагляднее тем лучше всеравно
я не хочу проверять будет ли мой джун такой же как у тебя
все тупо прозаично
(Добавление)
юзабильность кода на первом месте
все остальное потом
не хотите? дело ваше