Так как SQL Server не имеет пакетов, что программисты делают для обхождения его?

Схемы могут использоваться для организации хранимых процедур и других объектов. Лично я предпочитаю использовать схемы, когда они организуют объекты по функциональным областям, и где эти функциональные области соответствуют границам безопасности. Пример этого можно найти в примере базы данных AdventureWorks, которая имеет такие схемы, как «HumanResources» и «Sales». Теория заключается в том, что конкретному пользователю может понадобиться доступ к объектам в «HumanResources», но может не потребоваться доступ к информации «Sales».

Альтернативой является использование соглашения об именовании и его применение, как говорит Джеймс выше. Я добавлю, что в SQL Server Management Studio есть кнопка фильтра, которую можно использовать для фильтрации списка отображаемых объектов. Например, можно нажать «Хранимые процедуры» папка и фильтр по имени содержат «Добавить».

В моем текущем проекте я извлек ряд SQL-запросов из пакетов служб SSIS и в хранимые процедуры. Чтобы различать эти хранимые процедуры и те, которые должны иметь общее использование, я поставил перед именами «ssis». Конечно, было бы более приятно, если бы я мог создать нечто похожее на пространство имен в C # или C ++ и создал бы «SSIS.SelectUserLookupData» вместо «ssis_SelectUserLookupData». Было бы еще лучше, если бы эти пространства имен могли быть вложенными.

Если это одна из особенностей Пакетов в Oracle, то, возможно, кто-то сообщит мне об этом.

Чтобы различать эти хранимые процедуры и те, которые должны иметь общее использование, я поставил перед именами «ssis». Конечно, было бы более приятно, если бы я мог создать нечто похожее на пространство имен в C # или C ++ и создал бы «SSIS.SelectUserLookupData» вместо «ssis_SelectUserLookupData». Было бы еще лучше, если бы эти пространства имен могли быть вложенными.

Если это одна из особенностей Пакетов в Oracle, то, возможно, кто-то сообщит мне об этом.

Чтобы различать эти хранимые процедуры и те, которые должны иметь общее использование, я поставил перед именами «ssis». Конечно, было бы более приятно, если бы я мог создать нечто похожее на пространство имен в C # или C ++ и создал бы «SSIS.SelectUserLookupData» вместо «ssis_SelectUserLookupData». Было бы еще лучше, если бы эти пространства имен могли быть вложенными.

Если это одна из особенностей Пакетов в Oracle, то, возможно, кто-то сообщит мне об этом.

Придумайте хорошее соглашение об именах, используйте его и применяйте его.

I would thank my lucky stars that SQL Server doesn't have packages. Oracle packages suck.

Hmm, we need a way to take all these procedures and put them in one place. I know! Let's make developers create and maintain two files for each package. They will love us forever!

As long as MS never implements packages like Oracle did, it'll be a win in my book.

EDIT for commenters:

Oracle Packages are simply a way to organize your stored procedures into, well, packages so that you don't have 100 stored procedures sitting around, but maybe 5 packages. They're not stackable like packages in Java or C# code. All packages are at the same level.

A package requires two files: the headers file and the body file. This creates frustration when adding new procedures to an existing package, because you cannot add the body without adding the header, even though it contains the exact same information as is in the body.

For example, here is a snippet from the header file of one of my packages:

    PROCEDURE bulk_approve_events
(
    i_last_updated_by IN VARCHAR2,
    o_event OUT NUMBER
);

And here's the corresponding procedure in the body:

    PROCEDURE bulk_approve_events
(
    i_last_updated_by IN VARCHAR2,
    o_event OUT NUMBER
) IS
...
BEGIN
...
END;

No difference. The header file is useless and is simply another hurdle for the developer to step over when developing with packages. On my project, we have a convention that all the commented documentation for each procedure goes in the header, along with the details of when it was added and by whom, but that could just as easily be included in the body.

Я работал как с SQL Server, так и с Oracle, поэтому видел и хорошие, и плохие. Поскольку приведенные выше комментарии были немного горячими, я постараюсь сохранить их как можно более нейтральными ...

Итак, что такое пакет Oracle? Думайте об этом как о классе базы данных

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

Элемент тела пакета содержит все сохраненные процедуры и логику, которые фактически выполняют работу. В заголовке пакета может быть объявлена ​​процедура сохранения, которая вызывает процедуру вставки или обновления, существующую в теле. Разработчик может видеть только процедуру «Сохранить». Важно помнить, что тело пакета также может реализовывать процессы или функции, не объявленные в заголовке пакета, они просто недоступны вне самого пакета.

Я обнаружил, что пакеты действительно полезны по ряду причин :

1. У вас есть концепция открытого интерфейса, который может быть предоставлен другим разработчикам.
2. Пакеты могут отражать ваши скомпилированные классы. Мой метод Orders.Save () C # вызовет мой метод Oracle Orders.SaveLineItem для сохранения каждой позиции и метод Oracle SaveOrder для сохранения деталей сводки заказа.
3. Мои процедуры сгруппированы вместе в пакетах красивым и логичным образом

Лично