何百ものエイリアス/シノニムvsデータベーステーブルの完全修飾名

Question

複数のスキーマに数百のデータベーステーブルがある場合、ストアドプロシージャとビューを作成するときにエイリアス/シノニムまたは完全修飾名を使用することをお勧めしますか？そのようないくつかにschema.table考えると、

Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities 

私は修飾名を使用すると、パフォーマンスがわずかに増加を期待していますが、このようなOrders.Customersなどの表は、Sales.Customersに移動しなければならない場合、私はどちらかだろうOrders.Customersを参照する既存のビュー/プロシージャを変更するか、またはそのような移動が予想される前に同義語を使用します。私はシノニムを使ってコードをテストに移すことに価値があると同時に、/ devをテストして同義語を必要としない私のプロダクション環境のレプリカを作成することもできます。

SQL Server Books Onlineは、完全修飾名を常に使用することをお勧めします。一部の友人は、数百の表のそれぞれに対して同義語を作成し、同義語のみを使用することを提案しています。私は完全修飾名（より読みやすく自明のコード、参照されるオブジェクトがどんなスキーマに属しているか、そしてschema.tableをタイプする習慣を知っている）を使用することを好みますが、パフォーマンス、操作性、可読性シノニムと完全修飾テーブル名を使用していますか？

Answer 1

テーブルが実際に動き回っていることが予想される場合は、安全であるように完全修飾名を使用してください。

Answer 2

私は常にクエリでエイリアスを使用します。主な理由の1つは、クエリが読みやすくなることです。完全なテーブル名を何度も何度も繰り返して、コードを騒がせます。

ほとんどの場合、テーブル名は非常に濁っていますが、フィールド名の由来は明らかです。ただし、フィールドを取得するテーブルを常に指定する必要があります。これにより、クエリのメンテナンスが容易になり、データベースの変更が感知されなくなります。

クエリは通常、いくつかのテーブルのみを使用し、関連するので、使用されるテーブルを追跡するのは簡単です。そうでない場合は、エイリアスが何を意味しているかを判断するもう1つのステップであり、情報はクエリ内で使用可能です。

テーブルを別のデータベースに移動する必要がある場合は、エイリアスも役立ちます。完全なテーブル名はクエリで一度だけ指定されるため、変更するのが簡単です。

同じフィールドを指定するさまざまな方法の間にパフォーマンスに違いがある場合、それはクエリの解析中のみであり、最小限に抑えることができます。クエリが実行されている場合、パフォーマンスの差はまったくありません。

Answer 3

これは「それに依存する」種類の状況です。

個人的には、複数のスキーマにまたがる表を持つアプリケーションでは、自分のコードのどこにでもスキーマ名をハードコードしたくないのですが、その目的のために、プライベートのコードを持つ各スキーマの同義語を作成します。

このように、テーブルをあるスキーマから別のスキーマに移動したり、（さらに悪いことに）スキーマの名前を変更した場合、すべてのコードとビューを処理するのではなく、そのスキーマを指すシノニムを更新する必要があります。

一方、私はスキーマを明示的に参照するコードを書くことを好みました。これは複数のスキーマで同じテーブルを参照しなければならないデータ移行プロジェクトのコードであり、スキーマ名がDEV/TEST/etcで動作するように、シノニム全体を大量に必要とせずにスキーマ名を「削除」する必要があります。

Answer 4

コード（SQLまたはストアドプロシージャ）は、データベース外のソースコード管理システムに残す必要があります。正確に検索や置換ができない場合は、深刻な問題があります。

テーブルの数が多い場合は、実際に接頭辞を使用する必要があります。 Sales.CustomerではなくREF_Customer。

ドットは、それが別のデータベース（MSおよびSybase）またはスキーマ（DB2およびOracle）にあることを示します。これは別の回復ユニットなので、別々に管理されているため、サーバーは境界を越えるたびにコンテキストを切り替える必要があります。したがって、これを念頭に置いてテーブルを適切に収集し、数多くではなくいくつかのデータベース/スキーマを使用する必要があります。例えば。頻繁に更新されず、他のdbs /スキーマから一般に参照される参照テーブルを分離します。

SQLコードでは、必ず完全修飾名を使用してください。列名の接頭辞ではなく、すべてのWHERE句とFROM句で使用します。これは、データベース/スキーマや環境、DEVをUATまたはPRODに移動するときに大きく役立ちます。

Answer 5

私の2セント...個人的に

、私が働いている会社は、同じスキーマ内のオブジェクトを参照する場合でも、完全修飾オブジェクト名を使用していました。まれに、別のスキーマにテーブルを移動したときに、過去の再検証の問題によって主に後からの互換性が失われたため、古いロケーションにビュー（シノニムではない）を設定します。

少なくともOracleでは、シノニムの名前を解決してからターゲットオブジェクトの名前（テーブル/ビュー/パッケージ/名前）を解決する必要があるため、等。）。パブリック・シノニムのパフォーマンスはわずかに向上しています（パブリック・シノニムの2倍）。しかし、これは多少争われている。詳細については、this Ask Tom articleを参照してください。しかし、あなたがデータベースを制限しない限り、私はそれについて心配しません。

Answer 6

質問には常に以上の答えがあります。それが「それは依存している」が常に正しい答えである理由です。私はあなたが意図に本当にとどまり、最後にあなたをデザインすると、先に出てくることが分かります。

スキーマは名前空間分離のために設計されています。たとえば、SaaSシステムを設計する場合、複数のテナントに対する懸念を分離するためにスキーマを非常に効果的に使用できます。また、スキーマを使用して、テストを本番から、または1つのアプリケーションデータを別のものから分離することもできます。テーブルだけでなく、ストアドプロシージャや他のすべてのデータベースオブジェクト用です。

DB2は、特殊レジスタを提供し、あなたが非修飾オブジェクト名をコーディングしますが、単純にそうようにCURRENT SCHEMA特殊レジスターを設定することにより、右スキーマに切り替えることができますCURRENT SCHEMA呼ば：

SET CURRENT SCHEMA = 'Production' 

これを、私の意見では、シノニムを使用するよりもはるかに優れたアプローチです。