У меня есть база данных SQL Server, которая имеет огромное количество хранимых процедур. Большое количество хранимых процедур не является проблемой в моих базах Oracle из-за функции пакета "Oracle".
Что делают программисты, чтобы обойти отсутствие "пакетной" функции, подобной функции Oracle?
В то время как SQL Server не имеет ничего общего с "классными функциями" инкапсуляции и состояния пакета , как вы привыкли к, вы можете упорядочить хранимые процедуры в схемах.
В менеджере предприятия эти procs все еще перечислены вместе, что делает для HUGE treelist, если у вас есть сотни procs. Я тоже скучаю по организации и классным функциям пакетов Oracle. Однако все платформы имеют свои сильные стороны.
ПРИМЕЧАНИЕ. Написание хранимых процедур на языке .NET дает вам инкапсуляцию и состояние. Однако он по-прежнему не разделяет их в дереве EM каким-либо особым образом.
Придумайте хорошее соглашение об именах, используйте его и принудительно выполните его.
Схемы могут использоваться для организации хранимых процедур и других объектов. Лично я предпочитаю использовать схемы, когда они организуют объекты по функциональной области, и где эти функциональные области соответствуют границам безопасности. Пример этого можно найти в базе данных примеров AdventureWorks, которая имеет схемы, такие как "HumanResources" и "Sales". Теория состоит в том, что данный пользователь может нуждаться в доступе к объектам в "HumanResources", но может не нуждаться в доступе к информации "Продажи".
Альтернативой является использование соглашения об именах и обеспечение его соблюдения, как говорит Джеймс выше. Я добавлю, что в SQL Server Management Studio есть кнопка фильтра, которая может использоваться для фильтрации списка отображаемых объектов. Например, можно щелкнуть по папке "Хранимые процедуры" и фильтровать по имени "Добавить".
В моем текущем проекте я вытащил несколько SQL-запросов из пакетов SSIS и в хранимые процедуры. Чтобы различать эти хранимые процедуры и те, которые должны быть общего использования, я префиксировал имена с помощью "ssis". Было бы, конечно, приятнее, если бы я мог создать нечто похожее на пространство имен на С# или С++ и создать "SSIS.SelectUserLookupData" вместо "ssis_SelectUserLookupData". Было бы даже лучше, если бы эти пространства имен были вложены.
Если это одна из задач Packages в Oracle, тогда, возможно, кто-то даст мне знать.
Я работал как с SQL Server, так и с Oracle, поэтому видел и то, и другое. Поскольку приведенные выше комментарии были немного нагреты, я попытаюсь сохранить это как можно нейтральнее...
Итак, что такое пакет Oracle? Подумайте об этом как о классе базы данных
Пакет имеет два элемента: заголовочный файл и файл body. Заголовочный файл является вашим общедоступным интерфейсом и содержит подпись (имя, параметры и тип возвращаемого значения, если применимо) всех хранимых процедур или функций (в Oracle функция возвращает значение, а хранимая процедура не является), которые могут быть напрямую вызваны. Тело пакета должно реализовать все сигнатуры процедуры в файле заголовка пакета.
Элемент body пакета содержит все хранимые процедуры и логику, которые фактически выполняют работу. У вас может быть процедура сохранения, объявленная в заголовке пакета, которая вызывает вставку или обновление proc, которые существуют в теле. Разработчик может видеть только процесс "Сохранить". Важно иметь в виду, что тело пакета может также выполнять procs или функции, не объявленные в заголовке пакета, они просто недоступны вне самого пакета.
Я нашел пакеты действительно полезными по нескольким причинам:
Лично я буду любить MS, чтобы реализовать какую-то функциональность пакета, поскольку я думаю, что он делает более чистую базу данных.
1) Как и люди, Schema является более логичным и ANSI-совместимым способом организации таблиц и процедур базы данных.
2) Наилучшая практика разработки программного обеспечения заключается в том, что мы никогда не должны делать изменения непосредственно на любом сервере. Поскольку все sprocs базы данных написаны сценарием и находятся под контролем конфигурации, мы можем организовать эти сценарии в любую структуру папок, которую мы хотим.
3). Лучший аргумент против пакетов oracle - это то, что на основе опыта и исследований на сайте Ask Tom невозможно обновить пакет, не снимая его. Это неприемлемо. С SQL Server мы можем обновлять хранимые процедуры "на лету", не прерывая производственную работу.
Обновление: WeMartin, вы говорите: "В реальной производственной среде изменения никогда не должны тестироваться в процессе производства. Обновления должны быть перенесены из тестовой среды в производство по расписанию и упорядоченно. В системе 24/7, затем избыточную рабочая среда должна обрабатывать время простоя при обновлении серверов".
Я вовсе не подразумеваю, что ЛЮБЫЕ изменения проверяются на производстве. Даже если изменения будут протестированы в 9 более низких средах разработки, эти полностью и тщательно протестированные изменения должны быть развернуты на производственном сервере. В этот момент, используя пакеты Oracle, производственный сервер должен быть сбит во всех случаях, даже для небольших изменений sproc.
3). Лучший аргумент против пакетов oracle - это то, что на основе опыта и исследований на сайте Ask Tom невозможно обновить пакет, не снимая его. Это неприемлемо. С SQL Server мы можем обновлять хранимые процедуры "на лету", не прерывая производственную работу.
Я понимаю разочарование этого утверждения, но я бы не назвал id "неприемлемым". В настоящей производственной среде изменения никогда не должны проверяться в процессе производства. Обновления должны перемещаться из тестовой среды в производство по расписанию и упорядоченно. В системе 24/7 тогда избыточная производственная среда должна обрабатывать время простоя при обновлении серверов. Мало того, что пакет должен быть снят с линии, но новый пакет, если он не скомпилирован, сработает, если он будет снова включен. Для баз данных Oracle требуется элемент DBA. Однако я пропускаю пакеты Oracle.
Еще одна особенность пакетов, о которых не упоминалось, - это возможность "обернуть" тело. Заголовок всегда открыт и может быть просмотрен любым, у кого есть разрешения на выполнение пакета. Но это также позволяет им просматривать код в теле. Вы можете обернуть тело, зашифровать его и не дать кому-либо узнать, что делает этот код. Его приятная особенность, где безопасность - большая проблема.
Я хотел бы поблагодарить моих счастливых звезд, что SQL Server не имеет пакетов. Пакеты Oracle сосут.
Хм, нам нужен способ принять все эти процедуры и поставить их в одном месте. Я знаю! Пусть разработчики создают и поддерживают два файла для каждого пакета. Они будут любить нас навсегда!
Пока MS никогда не реализует такие пакеты, как Oracle, это будет победой в моей книге.
EDIT для комментаторов:
Oracle Packages - это просто способ организовать ваши хранимые процедуры, в том числе, пакеты, чтобы у вас не было 100 хранимых процедур, а возможно 5 пакетов. Они не складываются, как пакеты в Java или С#. Все пакеты находятся на одном уровне.
Пакет требует наличия двух файлов: файла заголовков и файла body. Это создает разочарование при добавлении новых процедур в существующий пакет, потому что вы не можете добавить тело без добавления заголовка, хотя он содержит ту же информацию, что и в теле.
Например, вот фрагмент из файла заголовка одного из моих пакетов:
PROCEDURE bulk_approve_events
(
i_last_updated_by IN VARCHAR2,
o_event OUT NUMBER
);
И вот соответствующая процедура в теле:
PROCEDURE bulk_approve_events
(
i_last_updated_by IN VARCHAR2,
o_event OUT NUMBER
) IS
...
BEGIN
...
END;
Никакой разницы. Файл заголовка бесполезен и является просто еще одним препятствием для разработчика при разработке с пакетами. В моем проекте у нас есть соглашение, согласно которому вся прокомментированная документация для каждой процедуры содержится в заголовке, а также сведения о том, когда она была добавлена и кем, но это можно было бы легко включить в тело.