Длинно:
Если не считать древних времен, когда писали все так, то относительно недавний кейс достаточно простой: С коллегой присоединились к достаточно большой команде (10 бэкендеров, 2 тимлида) команде в качестве контракторов. Системе примерно 10 лет, основа бизнес логики была написана примерно тогда же на PgSQL в виде кучи хранимок, при этом вся остальная система представляла из себя модульный монолит, написаный на другом языке. По большей части вся валидация, обработка ошибок и прочее содержалось как раз в нем, кроме собственно манипуляций с основными данными, для этого использвался вызов этих самых хранимок.
При этом миграции структуры таблиц были через стандартные средства фреймворка, а миграции хранимок - через SQL-файлы в гите, которые подгружались через специальную консольную команду. Проблем было несколько:
1. Хранимки хорошо знал один из тимлидов (который, собственно и написал их), однако в команде в целом не сильно знали как писать их правильно, прихоидлось много рыскать по мануалам или спрашивать у него лично. Лично меня спасало то, что когда-то я на Оракле с этим работал в студенчестве, что-то помнил из тех времен.
2. Для разработки мы использовали докер, в котором крутился Postgres, но для дев-образа не был установлен модуль для деббагинга, что выливалось в необходимость отладки методом внимательно разглядывания кода или аналогом dbms_output / выбросом исключений. Я пробовал сам его прикрутить, однако тогда не настолько знал докер, поэтому потерпел неудачу и оставил это занятие, благо задач на хранимки было не так много.
3. Ещё одна проблема была в том, что в проекте использовался ребейз. Код мерджить мог только тимлид, однако ввиду занятости он иногда делал это ночью, когда его никто не отвлекал с запросами. Поскольку он мерджил по неск. МР-ов за раз, то можно было неправильно померджить с потерей информации. У моего напарника был случай, когда в одну из таких ночей тимлид неправильно померджил одну из хранимок которую переписал коллега, в результате процедура отрабатывала нормально кроме некоторых кейсов. Поскольку баг выпал как раз на коллегу и он смог заметить, что код хранимки какой-то странный, сравнив файл с текстом со своей локальной веткой, то он смог найти причину достаточно быстро. Что было бы, если версионировалось все в бд - хз, думаю, проблем было бы больше.
В целом, надо сказать, оба тимлида понимали необходимость ухода от бизнес-логики в хранимках и был выбран курс на постепенный отказ от этого, но, поскольку времени на рефакторинг было мало, то особо мы в этом направлении не продвинулось за тот год, что я был на проекте, как сейчас там - неизвестно.
Уж никак не думал, что меня объявят пассивно-агрессивным, однако, извиняюсь, если это так звучит. Скорее, я пытался дать альтернативный взгляд на проблему, потому что вопрос интересный.
1. -
2. А какой параметр мы пытаемся оптимизировать? Обычно ставят в основу быстроту разработки, которая состоит в легкости поддержки и внесения изменений в код, соответственно, зачем преодолевать трудности именно в этом?
3. Мой опыт полностью противоположен, я уверен, что за 10 лет поменяется полностью архитектура проекта и не один раз как раз из-за изменения требований. естественно, это будет происходить не одномоментно. Впрочем, против уверенности мне возразить нечего.
4. А бизнес-логика разве в таком случае не будет распределена уже на 2 слоя: БД и модуль на с++, который надо ещё как-то скомпилировать?
5. Ну в целом, для кэширования просто можно было бы использовать стороннее хранилище, например, Redis, что увеличило бы скорость работы системы, а также снизило бы загрузку основной БД. Что касается множества инстансов БД, то возникают вопросы реплицирования и партиционирования данных и БЛ, которые тоже, возможно, могли бы быть решены гораздо проще.
6. Если у вас именно такой проект - вполне можно.
Поймите, все зависит от требований и насколько быстро надо менять бизнес-логику. Есть до сих пор системы в эксплуатации, которые написаны на BASIC, Cobol, Delphi или ещё на чем-нибудь древним и их пока не переводят по целому ряду причин.
З.Ы. В целом, сложилось впечатление, что у вас есть какой-то определенный специфичный случай, который вы не описываете, но пытаетесь решить. Я рекоммендую не закцикливаться на выбранном варианте, а рассматривать больше альтернатив. В конце концов, никто не спорит, что молоток - хороший инструмент, но применять его везде не всегда оправдано.
Из вопроса непонятно, что за данные "1|2|3|4|5". Это ID-шники записей из второй таблицы? Если да, то зачем была выбрана именно такая модель хранения?
Что значит "реализовать связанные таблицы"?
К сожалению, у меня jsfiddle почему-то никак не хочет открываться, возможно кто-то блочит, с ВПНами поборолся. Добавьте, пожалуйста, текстом или картинкой. На всякий случай напишите вашу почту или контакт в ТГ, попробую вечером глянуть, если будет время.
SharkMan, Не ошибся, увидев в первом комментарии/ответе предложение поюзать Шторм), однако все-таки хочется узнать: или это у меня руки кривые, или это netBeans кривая. Я все-таки исхожу из верности 1го предположения и отсутствия нормальной справки
Да, я видел этот компонент, теперь вопрос: как сделать чтобы по одному аттрибуту происходил поиск? Поскольку поля-то 2, в SearchModel запрос передается через get, то модель получает только второе значение и диапазона не получается.
На самом деле все работает, только проблема была в том, что в .htaccess был параметр, пытающийся задать mb.function_overload, чего теперь делать нельзя, поэтому значения брались по умолчанию. Насколько я понял, это идет ещё с версии 5.2.8.
Остался доп. вопрос, как правильно прописать это для nginx+PHP-FPM
Точно такой же случай как у вас, только CentOS, но решение не сработало: для папки все равно берется значение по умолчанию. Может ещё что-то необходимо было указать?
Длинно:
Если не считать древних времен, когда писали все так, то относительно недавний кейс достаточно простой: С коллегой присоединились к достаточно большой команде (10 бэкендеров, 2 тимлида) команде в качестве контракторов. Системе примерно 10 лет, основа бизнес логики была написана примерно тогда же на PgSQL в виде кучи хранимок, при этом вся остальная система представляла из себя модульный монолит, написаный на другом языке. По большей части вся валидация, обработка ошибок и прочее содержалось как раз в нем, кроме собственно манипуляций с основными данными, для этого использвался вызов этих самых хранимок.
При этом миграции структуры таблиц были через стандартные средства фреймворка, а миграции хранимок - через SQL-файлы в гите, которые подгружались через специальную консольную команду. Проблем было несколько:
1. Хранимки хорошо знал один из тимлидов (который, собственно и написал их), однако в команде в целом не сильно знали как писать их правильно, прихоидлось много рыскать по мануалам или спрашивать у него лично. Лично меня спасало то, что когда-то я на Оракле с этим работал в студенчестве, что-то помнил из тех времен.
2. Для разработки мы использовали докер, в котором крутился Postgres, но для дев-образа не был установлен модуль для деббагинга, что выливалось в необходимость отладки методом внимательно разглядывания кода или аналогом dbms_output / выбросом исключений. Я пробовал сам его прикрутить, однако тогда не настолько знал докер, поэтому потерпел неудачу и оставил это занятие, благо задач на хранимки было не так много.
3. Ещё одна проблема была в том, что в проекте использовался ребейз. Код мерджить мог только тимлид, однако ввиду занятости он иногда делал это ночью, когда его никто не отвлекал с запросами. Поскольку он мерджил по неск. МР-ов за раз, то можно было неправильно померджить с потерей информации. У моего напарника был случай, когда в одну из таких ночей тимлид неправильно померджил одну из хранимок которую переписал коллега, в результате процедура отрабатывала нормально кроме некоторых кейсов. Поскольку баг выпал как раз на коллегу и он смог заметить, что код хранимки какой-то странный, сравнив файл с текстом со своей локальной веткой, то он смог найти причину достаточно быстро. Что было бы, если версионировалось все в бд - хз, думаю, проблем было бы больше.
В целом, надо сказать, оба тимлида понимали необходимость ухода от бизнес-логики в хранимках и был выбран курс на постепенный отказ от этого, но, поскольку времени на рефакторинг было мало, то особо мы в этом направлении не продвинулось за тот год, что я был на проекте, как сейчас там - неизвестно.