Dimitry Sibiryakov,

В пакете обычно не смешивают процедуры, не объединённые общей бизнес-логикой или утилитарным функционалом. А вынесенный в отдельную таблицу ключ может использовать процедура, никак не связанная с логикой данного модуля. В вашем варианте, вызывая любую "чужую" процедуру, надо проверять, какие ключи она затрагивает.

Бумбараш,

а это и не киллер-фича. Просто удобство. Особенно, когда есть с чем сравнивать.

Согласен. Надо сразу писать ANSI-совместимый код, вынося всю логику на уровень приложений. Тогда подойдёт в общем-то любая СУБД, вплоть до использования файлов. Никаких процедур - это вендор лок в любом случае. Никаких управлений уровнями изоляции и блокировками. Никаких типов данных, кроме наиболее примитивных. Никакого функционала с агрегатными и тем более оконными функциями. Только CRUD.

Вот тогда не будет проблем при миграции, стопудово!


А, забыл. Никакого BI - это тоже же вендор лок. Только свой велосипед на чистом SELECT.

msLex,

Первое

Dimitry Sibiryakov,

Любая. В той же схеме, но выполняющая другой кусок бизнес-логики.

Dimitry Sibiryakov,

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

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

Я исхожу из работы над кодом команды, состоящей более чем из одного разработчика. Соглашение "один пакет - одна задача" выполнить гораздо проще, чем вести где-то взаимосвязь отдельных процедур, выполняющих связанный набор процессов. Проще отслеживать изменения, проще решать конфликты, проще ограничивать объём изменений. Проще оценивать, что затронут изменения.

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

Dimitry Sibiryakov,

Перелопатить сотню процедур в пакете
Сто процедур в пакете в большинстве случаев не требуется, т.к. это инкапсуляция логики отдельного процесса или утилитарного функционала, который можно и нужно декомпозировать на отдельные составляющие. Опережая вопрос, в этом случае вряд ли будет нужна некая общая переменная для всех процедур. А если такая нужна - выносится в пакет с глобальными переменными уровня сессии, где можно закрыть её через get/set-методы с проверкой вызывающего.

Или
просто у Вас не укладывается в голове существование схемы, созданной под три процедур
Нет, это Вам похоже очень сложно представить себе работу с пакетами, декомпозицию и инкапсуляцию логики. Лично я уже наелся при работе с sql server варианта "схема под три процедуры", спасибо, больше не хочется. Особенно, когда начинается рефакторинг общих вызовов с созданием новых схем.

В том, что "торчит наружу" только три, а остальные пользователю видеть и вызывать запрещено?
Пользователю (именно пользователю, т.е. приложению или вызывающему клиенту) не нужно знать код процедур. Ему достаточно знать контракт вызова в виде их сигнатуры, а не код реализации каждого метода. Не говоря уж о том, что у пользователя в принципе не должно быть возможности вызвать служебные методы, которые не предназначены для внешнего использования.

В обратную сторону - у postgresql есть замечательная штука с объявлением окна, общего для нескольких функций. Прям хочется такое же.

Честно говоря, не знаю, насколько сейчас хорошо в postgesql с секционированием, что можно, какие поддерживаются способы и сочетания. Может кто подсказать?

Dimitry Sibiryakov,

Расчехляйте плюсомёт, что уж там