選択クエリで必要な各列に具体的に名前を付ける必要があると多くの人が主張するのを見てきました。
とにかくすべての列を使用すると仮定すると、なぜ使用しないのSELECT *ですか？
* SQLクエリ-ビューから*を選択するか、ビューからcol1、col2、…colNを選択*する問題を考慮しても、少し異なる視点から問題に取り組んでいるため、これは正確な重複ではないと思います。
私たちの原則の1つは、時間になる前に最適化しないことです。このことを念頭に置くと、リソースの問題であることが証明されるか、スキーマがほぼ確定するまではSELECT *、使用することをお勧めします。これは、ご存じのとおり、開発が完全に完了するまで発生しません。
とはいえ、使用しないことの重要な問題はありますSELECT *か？
回答:
時期尚早の最適化ではないの引用の本質はシンプルでわかりやすいコードのために行くとすることで、次にあなたが効率的に最適化することができますホットスポットを、指摘してプロファイラを使用しています。
select *を使用すると、プロファイリングが不可能になるため、明確で簡単なコードを記述しておらず、引用の精神に反することになります。select *アンチパターンです。
したがって、列の選択は時期尚早の最適化ではありません。頭のてっぺんからいくつか...
その結果はselect *...
正しいSQLの記述は、記述と同じくらい簡単Select *です。したがって、本当の怠惰な人は適切なSQLを作成します。なぜなら、彼らはコードを再訪したり、それを行ったときに何をしていたのかを思い出したくないからです。彼らは、コードのすべてのビットについてDBAに説明したくありません。アプリケーションが犬のように動作する理由をクライアントに説明したくありません。
コードが特定の順序の列に依存している場合、テーブルが変更されるとコードが壊れます。また、*を選択すると、特にテーブルにバイナリフィールドがある場合、テーブルからフェッチしすぎる可能性があります。
ここですべての列を使用しているからといって、他の誰かがテーブルに列を追加しないわけではありません。
また、*に含まれる列を知るためにテーブルに関するメタデータをフェッチする必要があるため、プラン実行キャッシュにオーバーヘッドが追加されます。
主な理由の1つは、テーブルに列を追加または削除すると、SELECT *呼び出しを行っているすべてのクエリ/プロシージャが、予想よりも多いまたは少ないデータ列を取得するようになることです。
回り道では、可能な限り厳密な型指定を使用するというモジュール性の規則に違反します。Explicitはほぼ例外なく優れています。
テーブルのすべての列が必要になった場合でも、後でさらに追加することができ、クエリを実行するたびにプルダウンされ、パフォーマンスに悪影響を与える可能性があります。パフォーマンスが低下します
テーブルのすべての列を明示的に必要とするとき、クエリを書き込んだときに存在していたテーブルのすべての列が必要になるのとは対照的です。たとえば、テーブルの内容全体を表示する必要があるDB管理アプリを作成している場合（それらが何であれ）、そのアプローチを使用できます。
SELECT *するもう1つの時間は、dbクライアントを使用してテストクエリを実行しているときです。
いくつかの理由があります。
注：上記の例では、サイズが4バイトに固定されているため、INTEGERを選択しました。
アプリケーションがSELECT *を使用してデータを取得し、データベースのテーブル構造が変更された場合（たとえば、列が削除された場合）、アプリケーションは、欠落しているフィールドを参照するすべての場所で失敗します。代わりに、クエリにすべての列を含めると、アプリケーションは（うまくいけば）最初にデータを取得する1つの場所で中断し、修正が容易になります。
そうは言っても、SELECT *が望ましい状況はいくつかあります。1つは常に遭遇する状況で、テーブル全体を別のデータベース（SQL ServerからDB2など）に複製する必要があります。もう1つは、テーブルを一般的に（つまり、特定のテーブルに関する知識なしで）表示するように作成されたアプリケーションです。
select *SQL Server 2005のビューで使用すると、奇妙な動作に実際に気付きました。
次のクエリを実行すると、意味がわかります。
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
[id] [int] IDENTITY(1,1) NOT NULL,
[A] [varchar](50) NULL,
[B] [varchar](50) NULL,
[C] [varchar](50) NULL
) ON [PRIMARY]
GO
insert into dbo.starTest
select 'a1','b1','c1'
union all select 'a2','b2','c2'
union all select 'a3','b3','c3'
go
IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vStartest]'))
DROP VIEW [dbo].[vStartest]
go
create view dbo.vStartest as
select * from dbo.starTest
go
go
IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vExplicittest]'))
DROP VIEW [dbo].[vExplicittest]
go
create view dbo.[vExplicittest] as
select a,b,c from dbo.starTest
go
select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicitTest
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
[id] [int] IDENTITY(1,1) NOT NULL,
[A] [varchar](50) NULL,
[B] [varchar](50) NULL,
[D] [varchar](50) NULL,
[C] [varchar](50) NULL
) ON [PRIMARY]
GO
insert into dbo.starTest
select 'a1','b1','d1','c1'
union all select 'a2','b2','d2','c2'
union all select 'a3','b3','d3','c3'
select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicittest
最後の2つのselectステートメントの結果を比較します。あなたが見るものは、名前ではなくインデックスで列を参照するSelect *の結果だと思います。
ビューを再構築すると、再び正常に機能します。
編集
別の質問を追加しました。SQLServer 2005の興味深い動作「*テーブルからの選択」と「テーブルからのcolA、colBなどの選択」の興味深い動作 *を追加して、その動作を詳細に調べます。
SELECT *は常に悪であるとは限りません。私の意見では、少なくとも。テーブル全体といくつかの計算フィールドを返す動的クエリによく使用します。
たとえば、「通常の」テーブル、つまりジオメトリフィールドがなく、フィールドに座標が含まれているテーブルから地理的ジオメトリを計算したいとします。私はpostgresqlとその空間拡張postgisを使用しています。しかし、原則は他の多くの場合に適用されます。
例：
場所のテーブル。座標はx、y、zのラベルが付いたフィールドに保存されています。
CREATE TABLEプレース（place_id整数、x数値（10、3）、y数値（10、3）、z数値（10、3）、説明varchar）;
いくつかの例の値でそれを供給しましょう：
INSERT INTO Places（place_id、x、y、z、description）VALUES
（1、2.295、48.863、64、 'Paris、Place de l \'Étoile '）、
（2、2.945、48.858、40、' Paris、Tour Eiffel '）、
（3、0.373、43.958、90、'コンドーム、カテドラルサンピエール '）;
いくつかのGISクライアントを使用して、このテーブルのコンテンツをマップできるようにしたいと考えています。通常の方法は、ジオメトリフィールドをテーブルに追加し、座標に基づいてジオメトリを構築することです。しかし、私は動的クエリを取得したいと思います。このようにして、座標を変更すると（修正、より正確など）、マップされたオブジェクトは実際に動的に移動します。したがって、ここにSELECT *を使用したクエリがあります。
ビューを作成または置換するPlaces_points AS
SELECT *、
GeomFromewkt（ 'SRID = 4326; POINT（' || x || '' || y || '' || z || '）'）
FROM Places ;
GeomFromewkt（）関数の使用については、postgisを参照してください。
結果は次のとおりです。
SELECT * FROM Places_points;
place_id | x | y | z | 説明| geomfromewkt
---------- + ------- + -------- + -------- + ------------- ----------------- + -------------------------------- ------------------------------------
1 | 2.295 | 48.863 | 64.000 | パリ、エトワール広場| 01010000A0E61000005C8FC2F5285C02405839B4C8766E48400000000000005040
2 | 2.945 | 48.858 | 40.000 | パリ、エッフェル塔| 01010000A0E61000008FC2F5285C8F0740E7FBA9F1D26D48400000000000004440
3 | 0.373 | 43.958 | 90.000 | コンドーム、サンピエール大聖堂| 01010000A0E6100000AC1C5A643BDFD73FB4C876BE9FFA45400000000000805640
（3ライン）
右端の列をGISプログラムで使用して、ポイントを適切にマッピングできるようになりました。
VIEWの定義を*を使用して「そのまま」保持できることを願っていますが、そうではありません。これは、postgresqlによって内部的に格納される方法です。
SELECT Places.place_id、places.x、places.y、places.z、places.description、geomfromewkt（（（（（（（ 'SRID = 4326; POINT（' :: text || Places.x）|| ''： ：text）|| Places.y）|| '' :: text）|| Places.z）|| '）' :: text）AS geomfromewkt FROM Places;
テーブルの列が変更された場合にビューを再コンパイルする必要があるため、ビュー内で「select *」を使用することは一般的に好ましくありません。ビューの基になるテーブルの列を変更すると、戻って再コンパイルするまで、存在しない列に対してエラーが発生します。
他の誰も言及していないことを1つ追加するだけです。Select *すべての列を返します。誰かが後でデータを最後に更新した人やタイムスタンプ、またはマネージャのみがすべてのユーザーを見る必要はないというメモなど、必ずしもユーザーに表示したくない列を追加する可能性があります。
さらに、列を追加するときは、既存のコードへの影響を確認し、列に格納されている情報に基づいて変更が必要かどうかを検討する必要があります。を使用select *することにより、開発者は何も壊れないと想定するため、そのレビューはしばしばスキップされます。そして実際には、明示的に破損しているように見えるものはないかもしれませんが、クエリは間違ったものを返し始める可能性があります。明示的に壊れるものがないからといって、クエリに変更があったはずがないという意味ではありません。