22

ストアドプロシージャが急増しているSQLServerデータベースがあります。Oracleの「パッケージ」機能があるため、Oracleデータベースでは多数のストアドプロシージャは問題になりません。

Oracleのような「パッケージ」機能の欠如を回避するために、プログラマーは何をしますか？

4

9 に答える 9

29

SQL Serverには、これまでのようにカプセル化とパッケージ状態の「優れた機能」として提供できるものはありませんが、ストアドプロシージャをスキーマに整理することができます。

エンタープライズマネージャーでは、これらのプロシージャはすべて一緒にリストされているため、数百のプロシージャがある場合は膨大なツリーリストになります。私もOracleパッケージの構成と優れた機能が恋しいです。ただし、すべてのプラットフォームに長所があります。

注：.NET言語でストアドプロシージャを作成すると、カプセル化と状態が得られます。ただし、EMツリービューで特別な方法でそれらを分離することはありません。

于 2009-04-21T00:08:31.093 に答える
15

適切な命名規則を考え出し、それを使用して、それを適用します。

于 2009-04-20T22:11:38.363 に答える
8

スキーマは、ストアドプロシージャやその他のオブジェクトを整理するために使用できます。個人的には、スキーマを機能領域ごとに整理する場合、およびそれらの機能領域がセキュリティ境界に対応する場合に、スキーマを使用することを好みます。この例は、「HumanResources」や「Sales」などのスキーマを持つAdventureWorksサンプルデータベースにあります。特定のユーザーは「HumanResources」内のオブジェクトにアクセスする必要があるかもしれませんが、「Sales」情報にアクセスする必要はないかもしれないという理論です。

別の方法は、Jamesが上で述べたように、命名規則を使用してそれを強制することです。SQL Server Management Studioには、表示されているオブジェクトのリストをフィルター処理するために使用できるフィルターボタンがあることを追加します。たとえば、「ストアドプロシージャ」フォルダをクリックして、「名前に「追加」が含まれている」でフィルタリングできます。

現在のプロジェクトでは、SSISパッケージからストアドプロシージャに多数のSQLクエリをプルしました。これらのストアドプロシージャと一般的に使用されるプロシージャを区別するために、名前の前に「ssis」を付けました。C＃またはC ++で名前空間に似たものを作成し、「ssis_SelectUserLookupData」の代わりに「SSIS.SelectUserLookupData」を作成できれば、確かにもっと快適でした。これらの名前空間をネストできればさらに便利です。

これがOracleのパッケージの特徴の1つである場合、おそらく誰かが私に知らせてくれるでしょう。

于 2009-04-21T01:50:20.803 に答える
7

I've worked with both SQL Server and Oracle so have seen the good and bad of both. As the above comments have beena bit heated I'll try and keep this as neutral as possible...

So, what's an Oracle Package? Think of it like a database class

The Package has two elements: a header file and a body file. The header file is your public interface, and contains the signature (name, params and return type if applicable) of all the stored procedures or functions (in Oracle a function returns a value, a stored proc doesn't) that are directly callable. The package body must implement all the procedure signatures in the package header file.

The body element of the package contains all the stored procs and logic that actually do the work. You may have a Save procedure declared in the package header that calls an insert or update proc that exists in the body. The developer can only see the "Save" proc. It's important to keep in mind that the package body can also implement procs or functions not declared in the package header, they're just not accessible outside of the package itself.

I found packages to be really useful for a number of reasons:

  1. You've got the concept of a public interface that can be provided to other developers
  2. Packages can mirror your compiled classes. My Orders.Save() C# method will call my Oracle Orders.SaveLineItem method to save each line item and an Oracle SaveOrder method to save the order summary details.
  3. My procs are grouped together in a nice, logical way inside the packages

Personally, I would be love MS to implement some kind of package functionality as I think it makes for a cleaner database.

于 2009-08-07T12:47:53.207 に答える
2

言及されていないパッケージの1つの追加機能は、本体を「ラップ」する機能です。ヘッダーは常に公開されており、パッケージを実行する権限を持つすべての人が表示できます。しかし、それはまた、彼らが本文のコードを表示することを可能にします。本文をラップして暗号化し、コードが実際に何をしているのか誰にも見られないようにすることができます。セキュリティが大きな問題となる優れた機能です。

于 2013-08-21T13:29:19.407 に答える
1

3）Oracleパッケージに対する最良の議論は、Ask Tomサイトでの経験と調査に基づいて、パッケージをオフラインにしないと更新できないということです。これは受け入れがたい。SQL Serverを使用すると、本番運用を中断することなく、ストアドプロシージャをその場で更新できます。

私はこの声明の不満を理解していますが、idを「受け入れられない」とは呼びません。真の実稼働環境では、変更を実稼働環境でテストしないでください。更新は、スケジュールされた順序でテスト環境から本番環境に移動する必要があります。24時間年中無休のシステムでは、サーバーが更新されている間、冗長な実稼働環境でダウンタイムを処理する必要があります。パッケージをオフラインにする必要があるだけでなく、新しいパッケージをコンパイルしないと、オンラインに戻すと失敗します。Oracleデータベースに必要なDBA要素があります。しかし、私はOracleパッケージが恋しいです。

于 2013-01-03T15:04:46.083 に答える
1

そのような乾燥した主題をどのように感情的に乗り越えることができるかを見るのは少し面白いです。OracleにSQLServerの機能があるという事実は、この機能の議論の余地のある特性に対してあらゆる種類の反応を生成するわけではないようです。

手始めに、質問はスタイルにありました。SQLServerで見逃されているこの機能がOracleにあり、推奨されるアプローチは何ですか。

それについて感情的になる必要はありません。

Oracleのパッケージ化機能が気に入らない人は、理由が何であれ、SQLServerと同じようにそれを実行できます。

詳細を詳しく説明すると、スタイルにフォローアップの質問がある可能性があります。パッケージ内の関数またはプロシージャを変更すると、パッケージ全体が無効になり、これが「吸い込まれ」ます。吸い込みの側面を回避するための推奨される方法は何でしょうか。 。

個人的には、実行可能ファイル内の静的にリンクされたライブラリを再リンクせずに変更できないことについて不満を言う人を見たことがありません。

于 2020-05-21T18:16:47.163 に答える
0

  1. 人々が言っ​​ているように、スキーマはデータベーステーブルとプロシージャを整理するためのより論理的でANSI準拠の方法です。

  2. ソフトウェアエンジニアリングのベストプラクティスは、どのサーバーでも直接変更を加えてはならないということです。すべてのデータベースsprocはスクリプト化されており、構成の制御下にあるため、これらのスクリプトを任意のフォルダー構造に配置できます。

（AskTomから提供された古い情報は削除されました）

于 2012-03-09T19:55:29.450 に答える
-2

SQLServerにパッケージがないことを幸運な星に感謝します。Oracleパッケージは最悪です。

うーん、これらすべての手順を実行して1か所にまとめる方法が必要です。知っている！開発者に、パッケージごとに2つのファイルを作成して維持させるようにしましょう。彼らは私たちを永遠に愛してくれるでしょう！

MSがOracleのようにパッケージを実装しない限り、私の本ではそれが勝利になります。

コメント投稿者のための編集：

Oracleパッケージは、ストアドプロシージャをパッケージに編成するための単なる方法であり、100個のストアドプロシージャを配置するのではなく、5個のパッケージを配置することができます。JavaやC＃コードのパッケージのようにスタックすることはできません。すべてのパッケージは同じレベルにあります。

パッケージには、ヘッダーファイルと本文ファイルの2つのファイルが必要です。これにより、既存のパッケージに新しいプロシージャを追加するときにフラストレーションが生じます。これは、本文とまったく同じ情報が含まれている場合でも、ヘッダーを追加せずに本文を追加できないためです。

たとえば、私のパッケージの1つのヘッダーファイルからのスニペットは次のとおりです。

    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;

変わりはない。ヘッダーファイルは役に立たず、開発者がパッケージを使用して開発するときにステップオーバーするためのもう1つのハードルにすぎません。私のプロジェクトでは、各プロシージャのコメント化されたすべてのドキュメントが、いつ追加されたのか、誰によって追加されたのかという詳細とともにヘッダーに含まれるという規則がありますが、それは本文に簡単に含めることができます。

于 2009-04-21T20:19:01.510 に答える