Проблема состоит в невозможности использования переменной в качестве идентификатора объекта, например в качестве имени таблицы или имени столбца. Неприятная ситуация возникает в случае, если необходимо принимать имя объекта в функции и обрабатывать целевой объект, и при этом количество таких объектов велико (т.е. не клепать условные блоки для каждого конкретного объекта или, тем более, создавать отдельные процедуры для каждого объекта). Есть ли решение этой проблемы малой кровью? То есть без вариантов типа создания промежуточной таблицы с наследованием структуры, последующей обработки промежуточной таблицы, сопоставление с первоисточником и сохранением изменений в первоначальной таблице. Вариант использование представлений с сопутствующей группой правил на вставку, изменение и уделение записей тоже нежелателен.
Предлагаю
Предлагаю подумать вот над чем.
При создании процедуры, СУБД должна произвести ситаксическую и другие проверки правильности самой процедуры, а также скомпилировать её и сохранить в скомпилированном виде в базе.
Каким образом СУБД должна производить правильность проверки соответствия типов аргументов, а также корректность составленного SQL запроса внутри процедуры если ей заранее неизвестна таблица над которой этот запрос будет производится и как следствие неизвестно откажутся ли там запрошенные поля и какого они будут типа?
Конечно, на
Конечно, на этапе трансляции кода процедуры все идентификаторы в текстах запросов должны быть однозначно определены. Это понятно. Не понятно, как решить проблему необходимости обработки нескольких объектов одной процедурой с принятием имени объекта в качестве аргумента. Это же, вроде бы, типовые грабли при написании серверной логики. Сразу оговорюсь: структура базы данных от меня не зависит и существует уже довольно долго. То есть если бы можно было реорганизовать данные таким образом, чтобы подобной ситуации не возникало - то так бы давно и сделали. Красивым решением было бы, к примеру, динамическое создание однозначного глобального алиаса таблицы, имя которой принимается в качестве аргумента, и дальнейшее обращение к этой таблице через алиас. Но, судя по всему, подобное также не реализуемо. Единственные решения, найденные мной - это создание промежуточной таблицы с наследованием от целевой, перегоном данных, сравнением изменений и их фиксацией или же создание представления с полным комплектом следящих правил (разумеется, с указанием в правилах полных структур таблиц, которые еще могут и варьироваться). Что еще можно придумать на эту тему?
По-моему всё
По-моему всё придумано уже давно.
Вы пишите необходимые вам функции СНАРУЖИ СУБД, т.е. на клиенте.
Действительно, выгода хранимых процедур в быстром выполнении за счёт прекомпиляции. Но если это невозможно, то никакой разницы с внешним кодом по производительности я не вижу. Если же при этом на клиент будет сливаться куча информации по сети, что медленно и непроизводительно, то подумайте насчёт сервера приложений со схемой работы:
клиент<=>сервер приложений<=>СУБД