7

これはかなり明白な質問のように思えますが、私が尋ねようとしていることの適切な用語を考えることができなかったので、これに関する参考資料を思いつくのは難しいものでした. ただし、答えは明らかです。

Pluralsight の SQL Server のトレーニング資料を調べると、次のような「通常の」クエリ (基本的な Web サービス用に作成するもの) とストアド プロシージャ内の SQL クエリの両方で常にテーブルを参照することをお勧めします。

[databasename].[dbo].[some_table].[sometimesacolumngoeshere]

単純に以下を使用するストアド プロシージャなどに出くわすことは非常に一般的です。

my_column    or    [my_column]

ここでの違いは、一方が絶対的な「アドレス」を明示的に提供するのに対し、もう一方は暗黙的に提供することです。

どちらか一方を使用するのが適切な場合、またこれを何と呼びますか?

私の好みは常に明示的であることです。スペースを節約したり、物事をより明確にする必要がある場合は、明示的な完全な「アドレス」にエイリアスできますか？

4

7 に答える 7

6

あなたは正しいです。基本的に、SQL は、FROM セクションと JOIN セクションのすべてのテーブルで、探しているフィールド「my_column」を見つけようとします。ただし、テーブル A とテーブル B に "my_column" がある場合は、テーブル名を含めて、探している "my_column" を明示的に伝える必要があります。そこにも衝突がある場合、これは dbo および databasename へのチェーンを上ります。

ほとんどの場合、複数のテーブルを結合する場合を除き、列が含まれるテーブルを明示的に呼び出すことはありません。

たとえば、次のようにクエリを記述します。

SELECT a.field1, b.field2
FROM tableA AS a
INNER JOIN tableB AS b ON a.id = b.a_id
WHERE a.id = 123

ここでは、AS を使用して tableA と tableB をより読みやすい a と b にエイリアスしています。次のようにクエリを簡単に記述できます。

SELECT tableA.field1, tableB.field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123

または、このように、field1 と field2 がそこのテーブルに固有である場合、これは各データがどこから来ているかについて少し混乱します。

SELECT field1, field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123
于 2012-04-05T17:03:37.777 に答える
2

SQL Server には 4 つの部分名があります。

  • ほとんどの場合、名前でオブジェクトを参照します

    SELECT * FROM MyTable

  • 次に、オブジェクトの所有者またはスキーマを指定できます。

    SELECT * FROM dbo.MyTable

  • 次に、オブジェクトが存在するデータベースを参照できます。

    SELECT * FROM master.dbo.MyTble

  • 最後に、別のサーバー上のテーブルを参照できます

    SELECT * FROM test1.master.dbo.MyTable

MSDNで私ができるよりもよく説明されています

于 2012-04-05T16:59:53.643 に答える
2

列に暗黙的な名前を使用することは可能ですが、保守性の観点からは不適切な選択です。私は、すべての列に別名を付けない実動コードを出したことはありません。なぜなら、1 年後に戻ってそのレポートまたはクエリを変更するときに、結合した 20 のテーブルのどれに結合したかを知る必要が本当にないからです。さらに、指定しないと、データベースが列を見つけるのが難しくなり、参照なしで 2 つのテーブルに同じ列名がある場合、より多くのエラーをコーディングすることになります。明示的な参照を使用するのは良い習慣です。

于 2012-04-05T17:06:08.260 に答える
2

Pluralsight は間違っています。

同じデータベース内のオブジェクトを参照する完全修飾名を使用するストアド プロシージャの例を考えると、そのように完全修飾しない理由がさらに 2 つあります。

  • 同じデータベース内のオブジェクトを参照するストアド プロシージャがある場合、データベースの名前を変更すると、ストアド プロシージャが破損します。

  • データベース スクリプトをソース管理に追加するために Visual Studio データベース ツールの使用を開始した場合、対処すべき多くの警告が表示されます。

スキーマを正しく理解して活用することは良い考えです

于 2016-02-14T23:08:08.317 に答える
1

これは主観的な質問の 1 つであり、好みの問題になると思いますが、

読みやすさの観点から、必要な場合にのみ明示的であることを主張します。多くの場合、SQL ステートメントは十分に複雑であり、多くの不要なテキストを読む必要はありません。

と思います

SELECT TOP 1000 [StoreNumber]
      ,[Address1]
      ,[Address2]
      ,[City]
      ,[St]
      ,[Zip]
      ,[ZipSuffix]
      ,[LocationType]
      ,[LocationSubType]
      ,[Corp]
      ,[Division]
      ,[ZoneNumber]
      ,[DistrictNumber]
      ,[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]

よりもはるかに読みやすいです

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[Address1]
      ,[CommonData].[dbo].[vw_StoreData].[[Address2]
      ,[CommonData].[dbo].[vw_StoreData].[[City]
      ,[CommonData].[dbo].[vw_StoreData].[[St]
      ,[CommonData].[dbo].[vw_StoreData].[[Zip]
      ,[CommonData].[dbo].[vw_StoreData].[[ZipSuffix]
      ,[CommonData].[dbo].[vw_StoreData].[[LocationType]
      ,[CommonData].[dbo].[vw_StoreData].[[LocationSubType]
      ,[CommonData].[dbo].[vw_StoreData].[[Corp]
      ,[CommonData].[dbo].[vw_StoreData].[[Division]
      ,[CommonData].[dbo].[vw_StoreData].[[ZoneNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[DistrictNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]

(テーブルの結合を開始すると悪化し、異なるデータベース間でテーブルを結合するとさらに悪化します。)

クエリだけを見て、特定のフィールドがどのデータベース、スキーマ、およびテーブルから来ているかを正確に知る必要がある場合、2 番目の方が読みやすいと主張できる場所がわかります。

しかし、たとえば SQL Server では、そのクエリをデザイナーで開いて、より使いやすいグラフィカル ビューで表示できます。

私見ですが、完全な構文を使用するのは、必要な場合、テーブル/データベース/スキーマの境界を越える場合、または同じフィールド名を持つ 2 つのテーブルがある場合のみです。

例：

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
      ,[Address1]
      ,[Address2]
      ,[City]
      ,[St]
      ,[Zip]
      ,[ZipSuffix]
      ,[LocationType]
      ,[LocationSubType]
      ,[Corp]
      ,[Division]
      ,[ZoneNumber]
      ,[DistrictNumber]
      ,[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]
  Inner Join [CommonData].[dbo].[vw_StorePhones]
   ON [CommonData].[dbo].[vw_StorePhones].[StoreNumber] = [CommonData].[dbo].[vw_StoreData].[StoreNumber]

その場合でも、テーブル エイリアスを使用して短くし、読みやすくします。

とはいえ、現実の世界では、標準フォーマットがすでに決まっている会社で働いている可能性が高く、その会社の標準に従ってコーディングする必要があります。

于 2012-04-05T17:00:41.037 に答える
1

オブジェクトは、1 つまたは複数の識別子を介して参照できます。

単一の識別子を使用してオブジェクトを参照できますが、識別子があいまいな場合は、さらに多くの識別子を使用してオブジェクトを一意に識別する必要があります。

たとえばTableA、異なるスキーマに存在する名前が付けられた 2 つのテーブルは、少なくとも 2 つの識別子を使用してクエリで参照する必要がありschema_one.TableAますschema_two.TableA。

オブジェクト名と識別子について詳しく知ることができるMDSN ページがあります。

オブジェクト名に複数の識別子を使用することに関して、より具体的に説明すると、クエリのあいまいさが軽減され、クエリの解析が高速化されます。データベース エンジンがあいまいさの問題を解決する必要がないためです。クエリ。

私の個人的な好み (最も一般的に使用されるオブジェクト) は、クエリで単一のテーブルが参照される場合、およびクエリで複数のテーブルが参照される場合に、schema.Tableテーブル および を参照するときにを使用することです。columntable.column

于 2012-04-05T17:06:54.453 に答える