хранимая процедура для создания представления - PullRequest
Новая
       6

хранимая процедура для создания представления

1 голос
/ 11 февраля 2011

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

create or replace view MyView as
SELECT
   A.COLUMN_A
   FUNCTION1(to_date('2/10/2011','MM/DD/YYYY') TOTAL1,
   FUNCTION2(to_date('2/15/2011','MM/DD/YYYY') TOTAL2
FROM TABLE_A A;

Это представление затем используется для генерации данных, необходимых для отчета в кристалле.Проблема в том, что мы собираемся начать использовать те же операторы SQL на другом языке.(в настоящее время мы используем delphi, но для работы на другом языке (но я не знаю, что это за другой язык)) причина, по которой я хочу создать представление в хранимой процедуре, заключается в том, что a) представление является динамическим и основано надиапазон дат, выбранный пользователем и b) вместо того, чтобы вводить довольно большие представления на нескольких языках (которые должны создаваться на лету из-за изменения диапазона дат) на одной строке для функции и параметровнужно будет пройти.Многое из того, что я прочитал, говорит, что использование динамического SQL для создания представления - это плохо, но, зная, что это уже динамическое представление, созданное специально для пользователя на лету, кто-нибудь видит проблему с этим?Я спрашиваю, потому что я не хочу втягивать себя в то, что я не смогу вытащить из себя, не желая выдернуть все мои волосы.

Ответы [ 3 ]

2 голосов
/ 11 февраля 2011

Я делаю внешние интерфейсы Delphi и SQL Server. Зачем использовать вид? Я всегда просто создаю SP с простым SELECT, который делает работу очень хорошо. Если Crystal Report часто используется, что обычно имеет место), я просто создаю постоянную таблицу, которая очищается и заполняется каждый раз при запуске SP. Коротко, мило и просто.

1 голос
/ 11 февраля 2011

Генерация представления - это только хорошая идея, если она действительно генерирует код и в целом довольно постоянна.Поскольку это изменение схемы, его следует рассматривать как сложную технику, и я всегда стараюсь использовать методы базы данных в порядке сложности.

, т. Е. Для определенных конструкций таблиц / представлений, если это можно сделать с помощью представления, Попробуй это.Если индексированное представление действительно необходимо для производительности, попробуйте это.В качестве альтернативы может быть вычисляемый столбец или постоянный вычисляемый столбец.Возможно встроенная табличная функция или табличная функция с несколькими операторами или потенциально хранимая процедура.Поэтому я пытаюсь эскалировать только при необходимости.

В вашем случае это «представление» также может быть встроенной табличной функцией в SQL Server (и, по крайней мере, в DB2), и такое существо подобно параметризованномуПосмотреть.Вы также можете использовать параметризованную хранимую процедуру непосредственно из большинства инструментов отчетности (и, конечно, из большинства библиотек language / db).

1 голос
/ 11 февраля 2011

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

Риски и проблемы, с которыми вы можете столкнуться:

  • производительность: операторы DDL сделают недействительной часть вашего кэша, что плохо для производительности
  • фатальные ошибки: если другие вещи зависят от представления (хранимые процедуры, другие представления ...), они сломаются, если ваше представление прерывается по той или иной причине.
  • масштабируемость: DDL потребуется эксклюзивная блокировкана этом объекте.Получение этого может занять много времени и блокирует всех остальных, удерживая его.
  • масштабируемость: что произойдет, если двум пользователям необходимо одновременно изменить представление по-разному?
  • ремонтопригодность: Этостановится трудно понять, что происходит, когда объекты меняются на лету
  • безопасность: кто-то должен иметь право изменять эти объекты, которые могут быть использованы не по назначению для совершения злых дел.

В 99,9% не нужно динамическое создание объектов, и если у вас нет 0,1%, вы не должны их использовать.

Учитывая ваше описание задачи под рукой: Почему бы вам непросто используйте оператор sql с переменными частями в качестве переменных связывания и используйте это?Я не вижу необходимости в представлении здесь.

...