skillup

技術ブログ

Database

HAVING句の活用 発展編

投稿日:

今回からはまたまたHAVING句です。

下記のようなテーブル(teams)があり、全員が待機状態のチーム(全員がそろっている)を求めます。

member | team_id | status
——————+———+————-
ジョー | 1 | 待機
ケン | 1 | 出動中
ミック | 1 | 待機
カレン | 2 | 出動中
キース | 2 | 休暇
ジャン | 3 | 待機
ハート | 3 | 待機
ディック | 3 | 待機
ベス | 4 | 待機
アレン | 5 | 出動中
ロバート | 5 | 休暇
ケーガン | 5 | 待機

回答は下記のようになります。

team_id
———
4
3

これをNOT EXISTSとHAVINGを使って2パターンで記述する問題なのです。

HAVING

NOT EXISTS

本にも書いてありましたが、私もHAVINGのほうがわかりやすいですね。

CASEとHAINGは見た目がごつい割には理解しやすくフラグ的な扱いができるのでプログラマには向いている気がします。

ちなみにHAVINGを使って下記のように書く回答もありました。

一瞬わからなかったのですが、これはもしteam_id単位で複数のstatusが存在していたら最大と最小が違うという意味なんですね。分かりにくい場合はstatusを数字で考えるとよいと思います。

次は下記のテーブルで拠点ごとに資材のダブりをみるSQLです。

center | receive_date | material
—————–+————–+——————–
東京 | 2007-04-01 | 錫
東京 | 2007-04-12 | 亜鉛
東京 | 2007-05-17 | アルミニウム
東京 | 2007-05-20 | 亜鉛
大阪 | 2007-04-20 | 銅
大阪 | 2007-04-22 | ニッケル
大阪 | 2007-04-29 | 鉛
名古屋 | 2007-03-15 | チタン
名古屋 | 2007-04-01 | 炭素鋼
名古屋 | 2007-04-24 | 炭素鋼
名古屋 | 2007-05-02 | マグネシウム
名古屋 | 2007-05-10 | チタン
福岡 | 2007-05-10 | 亜鉛
福岡 | 2007-05-28 | 錫

下記のレコードが出力されればOKです。

center
—————–
東京
名古屋

これまた回答を見るとなんの変哲もないですが、意外にロジックが考えにくい題材だと思います。

要はダブりがなければ全体の列数とdistinctなmaterialの列数が一緒になるんですね。なのでそうなっていないケースを求めます。

ちなみに下記の書いてあげると全てのcenterのstatusがわかり大変みやすいです。

center | status
—————–+————
大阪 | ダブりなし
東京 | ダブりあり
福岡 | ダブりなし
名古屋 | ダブりあり

ちなみにEXISTSでもいけます。こちらだとダブっている素材もわかりますね。

-Database
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

CASE式のすすめ

SQL実践入門を7割がたぐらい終えたところで同著者の方の「達人に学ぶSQL徹底指南書」を学習しようと思っています。 この方の著書は気づいたら結構読んでましたね。 Contents1 CASE式での注意 …

no image

インデックスについて(SQLServer)

DBのインデックスについて、今までぼんやりと検索条件の効率化についてはしっていたのですが、もう少し掘り下げて理解する必要があるなと思い、メモります。 SQLServerのインデックスについてすごくまと …

no image

サブクエリ 移動平均など

前回の応用編です。 日付、入出金、残高はできましたが、ここからさらに、現在のレコードから3行以内(3行あれば3行、なければそれ以内でできるだけ)のレコードの合計値を出す計算を考えます。 結果だけ先に書 …

no image

外部結合について 行列変換

今回から外部結合について学習します。 これはCASE式でもやった集合の考え方が大事になってきます。 例えば下記のようなテーブルCoursesとがあるとします。 name | course &#8212 …

no image

データベース設計のアンチパターン 重すぎるOLTP+Date型不統一+データ量想定が甘い

Contents1 重すぎるOLTP1.1 デメリット1.2 対策2 DATE型の型の不統一2.1 デメリット2.2 対策3 データ量の想定が甘い3.1 デメリット3.2 対策 重すぎるOLTP ※O …

アーカイブ