DB設計を語るスレ 11

**NAME IS NULL** · 2021/08/28(土) 22:08:57.33

語れ

前スレ
DB設計を語るスレ 10
https://mevius.5ch.net/test/read.cgi/db/1495438711/

**NAME IS NULL** · 2023/07/30(日) 21:09:52.61

ここには理解している人が一人もいないと言うことが分かりました？

**NAME IS NULL** · 2023/07/30(日) 21:28:02.10

>>359
そう言われればそうだったｗ

**NAME IS NULL** · 2023/07/30(日) 21:37:29.99

>>351
セキュリティやプライバシー侵害につながるかどうかは
プライマリキー選定要件の一つではあるんだけど
これにひっかかるような項目はそれ以前の条件で基本的に弾かれる

**NAME IS NULL** · 2023/07/30(日) 21:53:44.23

>>380
あるなら説明すりゃいいってだけで。
それもせずにこうのらりくらりやるのは結局説明できないんだろう。

**NAME IS NULL** · 2023/07/30(日) 22:04:00.11

リンク間違えたか。
>>360
あんたが知ってる範囲のユースケースでは必要ないとしてもそれは「すべきではない」理由にはならんのよ。何度も書くけど。
そんな初歩の論理すら理解できないのかね。

**NAME IS NULL** · 2023/07/30(日) 22:04:57.72

>>363
あらゆる設計判断はトレードオフの判断だからさ
セキュリティやプライバシー侵害というデメリットを大きく上回るメリットがあれば許容されるんじゃね？
とは言っても公共系でマイナンバーをプライマリキーにしてたら相当やばいだろうけど

>>364
アンカ間違えてんぞ

**NAME IS NULL** · 2023/07/30(日) 22:23:26.73

時を掛けるDBマン

**NAME IS NULL** · 2023/07/30(日) 22:29:39.51

>>365
マイナンバーは法律で許可された特定業務以外でDB管理したら犯罪なのでユースケースは超限定されてる
だから登場人物と仕組みを理解してればユースケースがないこともわかる

ただ俺がユースケースを先に理解したほうがいいんじゃねと書いたのは知識として現実のユースケースを理解しろという意味ではなくどういうユースケースであればマイナンバーをプライマリキーにするのが妥当なのかを
自分の頭でまず考えたほうがいいよって意味だったんだけどね

いずれにしろユースケースの理解なしにプライマリキーの最終的な妥当性なんて判断できないでしょ

**NAME IS NULL** · 2023/07/30(日) 22:47:33.70

それが「すべきで無い」と言う理由なの？

**NAME IS NULL** · 2023/07/30(日) 22:50:42.19

>>368
>ただ俺がユースケースを先に理解したほうがいいんじゃねと書いたのは知識として現実のユースケースを理解しろという意味ではなくどういうユースケースであればマイナンバーをプライマリキーにするのが妥当なのかを
>自分の頭でまず考えたほうがいいよって意味だったんだけどね
.
ごくごく単純な話だと思うけどね。
一般に A → B という関数従属性があるときにA をキーとするテーブルで表現するのは普通のこと。
それを、A をキーにすべきではない場合があるとすればそれはどういう条件なのか。

法律の条文は知らんが、まさか「マイナンバーをプライマリキーに使ってはならない」と書いてあるわけじゃあるまい。

**NAME IS NULL** · 2023/07/30(日) 23:19:14.19

開始日、終了日というカラムが存在するテーブルがあるとします。
「期間指定なし」を実現したい場合、どうしますか？

A：期間指定なし用のカラムを追加する（is_unlimitedが1なら無制限になるとか）
B：開始日・終了日のカラムを「0000-00-00」（またはNULL）にする

という2パターンを思い浮かんだのですが、どちらがいいですか？
またはCパターンがあれば教えてください。

**NAME IS NULL** · 2023/07/30(日) 23:21:22.72

条文読んでみた。

行政手続における特定の個人を識別するための番号の利用等に関する法律
第二条
１０　この法律において「個人番号利用事務」とは、行政機関、地方公共団体、独立行政法人等その他の行政事務を処理する者が第九条第一項から第三項までの規定によりその保有する特定個人情報ファイルにおいて個人情報を効率的に検索し、及び管理するために必要な限度で個人番号を利用して処理する事務をいう。
第三条　
四　個人番号を用いて収集され、又は整理された個人情報が法令に定められた範囲を超えて利用され、又は漏えいすることがないよう、その管理の適正を確保すること。

「検索」や「整理」というのはキーとして用いることを想定しているように思えるが。

**NAME IS NULL** · 2023/07/30(日) 23:25:24.47

ナチュラルキーは運用・保守でデータを修正するときに面倒なことになる。

データの整合性は制約ではなく、アプリケーションが担保すればいい話。

理屈しか知らない経験不足のやつは、教科書に書いてあるようなことしか言わないw

**NAME IS NULL** · 2023/07/31(月) 01:24:43.95

複数のシステムから使うような基幹ＤＢで、１アプリのバグで整合性の崩れたデータが大量に発生したらとは考えないのかね
そんなことは起こらないとか思ってたら、それこそ経験不足だな

**NAME IS NULL** · 2023/07/31(月) 01:28:49.74

>>371
一般的にはBかな
開始日終了日はミドルウェアが取りうる範囲で事実上無期限の範囲を定義するパターンをよく見る

業務要件でAの方が良い場合もあればそっちでもいい

もっといいC案があるんかもしれん

現実の複雑さの前に教科書通りにやっても答えは出ない事が多い
何がベストなのかを考えるのがDB設計や

**NAME IS NULL** · 2023/07/31(月) 02:19:45.37

>>371
「期間指定なし」が
開始日・終了日という期間を指定する概念が当てはまらない種別のレコードを示すものなのか
期間がまだ指定されてない(未指定)のレコードを示すものなのか

前者なら種別を示すカラムを追加して開始日・終了日をNULLにする(A案)
もしくは種別を示すカラムを追加しつつサブタイピング
後者なら開始日・終了日をNULL(B案)

指定された期間の使われ方によってはもっと違うバリエーションがあるので
これも結論はユースケース次第

**NAME IS NULL** · 2023/07/31(月) 02:21:45.92

>>372
>「検索」や「整理」というのはキーとして用いることを想定しているように思えるが
んなわけあるかｗ

**NAME IS NULL** · 2023/07/31(月) 07:23:47.10

>>371
そこに期限がないことを示すならNULLが素直だが検索がやや面倒になるので
他に問題が起こらないならば開始日0000終了日9999という手もある。

**NAME IS NULL** · 2023/07/31(月) 08:08:15.76

>>377
そんな断言できるものなのか？

**NAME IS NULL** · 2023/07/31(月) 10:36:33.09

>>379
お前のキーの定義ゆるゆる過ぎるやろ
そら議論にならんわ

**371** · 2023/07/31(月) 15:18:31.82

みなさんアドバイスありがとうございます
範囲検索で必ずヒットさせたいので、
開始日（1000-01-01）、終了日（9999-12-31）のようにします
そして表示上は「期間指定なし」とします
こうすれば余計なカラムを追加せずに目的が実現できそうですね

**NAME IS NULL** · 2023/07/31(月) 15:32:40.41

終了日に9999は使わない方が良いと思う

**NAME IS NULL** · 2023/07/31(月) 15:38:26.72

終了日を指定しなければinfinite future扱いとするのはよくある話だけど
開始日を指定しなければinfinite past扱いとするのは聞いてことがないな
過去に遡らせる必要があることがないから

**371** · 2023/07/31(月) 15:53:50.88

それではこういうのどうでしょう？（MySQLです）

SELECT
*,
IF (date_s IS NULL AND date_e IS NULL, 1, 2) AS is_unlimited
FROM `posts`
HAVING (date_s <= '2023-07-01' AND date_e >= '2023-07-31') OR is_unlimited=1

date_s（開始日）、date_e（終了日）がともにNULLならis_unlimited（無制限）が1にし、
そうでない場合は2にしてから、HAVINGの条件に加えるとか

**NAME IS NULL** · 2023/07/31(月) 15:59:51.42

>>381
文字データ型を想定しているなら、開始日は意味のある業務日付にして、設計書に明記しろ。
開始日の西暦1000年は、データを見ても誰も意図がわからない。こういうのは登録ミスなんじゃないのかと、未来、必ず言われる。

**371** · 2023/07/31(月) 16:03:56.83

>>385
なるほど。そこまで考えていませんでした。
じゃ、適当な数値よりもNULLの方がマシですかね。
で、「date_sとdate_eがともにNULLなら期間指定なしとする」」
と設計書に明記すれば迷わない気がします。

**NAME IS NULL** · 2023/07/31(月) 16:05:18.32

>>384
開始日と終了日が必要なデータとそうでないデータがあるなら、複数データを同じ入れ物に入れようとしているアンチ正規化のちょっとよろしくない設計なんだが？

**371** · 2023/07/31(月) 16:08:46.81

>>387
ということは、>>371で書いたA案が正しいのですかね？
B案という意見も多いので、どっちが良いのかわからなくなります

**NAME IS NULL** · 2023/07/31(月) 16:39:20.99

どの程度の件数が格納されるか不明だけど検索項目になるなら自分ならNULLは許可しない
DB上の期間指定なしと入力可能な期間指定を明確に決めて設計するかな
DB上開始指定なしは0000-01-01、終了指定なしは9999-12-31、入力可能な期間指定は開始は2000-01-01、終了は2999-12-31など

**NAME IS NULL** · 2023/07/31(月) 16:53:35.14

開始指定なしはビジネスロジック上不明またはメンテ期間以前ってことだろ
前者ならNULLでもいいんじゃないか
3値論理の理想としてる設計だろ

**NAME IS NULL** · 2023/07/31(月) 16:55:12.55

検索項目にする場合、NULLだと都合が悪いのかな

**NAME IS NULL** · 2023/07/31(月) 17:05:41.13

開始終了の日付指定無し＝両方NULLを設定する
片方だけNULLは都合が悪い＝入力時にチェックするで対応
日付範囲指定で抽出＝範囲指定で、NULLデータは検索から排除されてる

これで上手く動くと思うけど、ダメなのかな？

**NAME IS NULL** · 2023/07/31(月) 18:32:11.87

>>392
テーブル上のケースは
A　開始：終了　開始～終了
B　開始：NULL　開始～
C　NULL：終了　～終了
D　NULL：NULL　期間なし
例えば日付範囲検索で
開始日以降の条件が発生した場合、開始≦条件の開始日 OR 開始 IS NULL
終了日以前の条件が発生した場合、終了≧条件の終了日 OR 終了 IS NULL
とそれぞれNULLの考慮が必要になるからNULLを持たないほうがいいんじゃない？
というのが自分の考えだわ
後は例えば開始が2023-01-01、終了が2023-12-31となっているデータがある場合に
2022-12-01～2023-03-31って検索した場合、上のデータが対象になるとNULLが混在するデータの場合に
条件も複雑にならないかね？

**NAME IS NULL** · 2023/07/31(月) 18:34:05.22

質問した人が果たしてそこまで要求してたかどうかは、あやしい

**NAME IS NULL** · 2023/07/31(月) 21:00:40.56

そういう意味でテーブルに開始・終了日付を持ち、検索時も開始・終了日付を持つ場合を考慮してNULLはないほうがいいと思ってる

**NAME IS NULL** · 2023/07/31(月) 21:33:37.76

DBにもよるけど検索時のIndexも効かないし
俺ならNULL使わないかな
3000万件から無期限のデータだけ取り出したい場合とかINDEX効かせないと辛いやろ

**NAME IS NULL** · 2023/07/31(月) 21:38:44.77

3000万件ですか？すごい大規模な案件ですね
そういうのを担当する人が果たしてここで質問するか、
大変興味があります

**NAME IS NULL** · 2023/07/31(月) 21:52:32.04

・NULLは駄目
・1000-01-01～9999-12-31のような最小、最大値を入れるのも駄目
・フラグ用のカラムを入れるのも駄目

ならどう設計するのが適切なの？

**NAME IS NULL** · 2023/07/31(月) 22:06:34.28

絶対にどれがダメなんてことはなくてそれぞれメリットデメリットあるからそれを踏まえて判断すればいい。
条件に関わらず「××は絶対ダメ」という奴がいるかもしれないがそういうのはバカだから無視していい。

**NAME IS NULL** · 2023/07/31(月) 22:08:57.28

>>396
>3000万件から無期限のデータだけ取り出したい場合
なんでそんなことしたいの？
3000万件から他のインデックス使わずに無期限のデータだけ取り出したい場合があるなら
無期限のデータと有期限のデータは根本的に種類が違うんじゃないの？

**NAME IS NULL** · 2023/07/31(月) 22:19:05.56

>>396
期限有り無しの二値だとインデックスも効きにくいだろ。よっぽど分布が偏ってない限り。
ビットマップインデックスもこの場合はちょっと違うしなあ。

**NAME IS NULL** · 2023/07/31(月) 22:33:24.14

二値しかないんだから、アクセス時間の方がかかる
インデックスあまり意味がない

**NAME IS NULL** · 2023/07/31(月) 22:40:21.82

>>401
インデックスをどうするか以前に
期限の有無が業務上持つ意味をDB設計に反映できてない可能性があるのではという話

よくあるのは通常の単価とキャンペーン単価の管理の違い
前者は開始日(=切替日)しかないが後者は開始日と終了日がある

**NAME IS NULL** · 2023/07/31(月) 22:56:02.47

本人がいないところで仕様を膨らますのは止めよう

**NAME IS NULL** · 2023/07/31(月) 23:07:24.63

>>396
>DBにもよるけど検索時のIndexも効かないし
オラクルだけじゃなくて？

**NAME IS NULL** · 2023/07/31(月) 23:14:10.03

オラクルでも今はNULLをIndexされるようにできるみたいね

**NAME IS NULL** · 2023/07/31(月) 23:16:19.49

SQLiteは知らないけど
SQL Server, MySQL, PostgresはどれもNULLがIndexingされるので
Oracleも大丈夫なら検索性能という意味ではあまり困らないような気がする

**NAME IS NULL** · 2023/08/01(火) 00:07:30.45

最近はOracleでもインデックスに含まれるのか知らなかったww勉強不足で申し訳ない

ただBTREE INDEXは魔法じゃないから
データ分布とか検索条件次第ですかね

**NAME IS NULL** · 2023/08/01(火) 08:13:04.34

>>403
そういうキャンペーン単価を管理するときって、別テーブルにするの？

▽商品テーブル
ID｜商品名｜価格｜登録日｜更新日

▽キャンペーンテーブル
ID｜商品ID｜キャンペーン価格｜開始日｜終了日

こんな感じ？
でもこれだと商品にキャンペーンがあるかわからないような気が

**NAME IS NULL** · 2023/08/01(火) 09:06:38.95

単価関連は標準単価とは別にキャンペーン用の単価を登録するテーブルを用意したりするんじゃない

**NAME IS NULL** · 2023/08/01(火) 09:39:35.55

キャンペーンの設計でいつも迷うのが履歴なんだよな
キャンペーン終了したからって削除すると、購入履歴がおかしくなるし

**NAME IS NULL** · 2023/08/01(火) 10:55:49.31

削除前提の設計なら履歴に削除するマスタの情報を付与しておけばいいんじゃない
でも普通というか使用されたマスタは削除なんてしないのでは

**NAME IS NULL** · 2023/08/01(火) 11:07:21.76

購入履歴は購入した各ユーザーの履歴として保存すれば良い

**NAME IS NULL** · 2023/08/01(火) 17:37:59.06

その履歴が何の履歴でどういう目的で残すものなのかを明らかにすれば設計はおのずと決まると思うが。

**NAME IS NULL** · 2023/08/01(火) 22:27:22.34

>>409
扱う商品や業種にもよるとおもうけど販売単価は頻繁に変更される場合は
商品名とかを管理する商品マスターには実際の販売単価は入れずに別にテーブルを作る
さらにそれとは別にキャンペーン用の単価を管理するテーブルを作る
(標準販売単価のような商品IDが決まれば一意に決まるような情報なら商品マスター)

適用される単価を割り出すのに2つ以上のテーブルを確認するというのはアプリロジック

>▽商品テーブル
>ID｜商品名｜価格｜登録日｜更新日
この設計だと価格を変更したい場合に価格を直接上書きするか商品IDを新しくするかしかなくて普通は困ると思う

**NAME IS NULL** · 2023/08/01(火) 23:26:21.41

開始日・終了日の件は
SQL標準に組み込まれたtemporal機能のsystem time periodsの実装方法を見ると
終了日だけオープンにしてdatetime型の最大値をセンティネルとして使ってるDBMSが大半のようなので
RDBMS固有の特別事情がなければそれがファーストチョイスでいい気がする

**NAME IS NULL** · 2023/08/02(水) 00:55:16.14

>>415
>>ID｜商品名｜価格｜登録日｜更新日
>この設計だと価格を変更したい場合に価格を直接上書きするか商品IDを新しくするかしかなくて普通は困ると思う
キャンペーンテーブルのほうに引きずられたけどよく考えたら
ID+更新日の複合主キーかそのサロゲートを使えば要件次第では困らないかもね

**NAME IS NULL** · 2023/08/02(水) 13:16:59.94

価格は適用日に応じた世代を持たせたテーブル作ると楽

**NAME IS NULL** · 2023/08/02(水) 13:32:20.34

適用日に応じた世代とかイミフｗ

**NAME IS NULL** · 2023/08/02(水) 13:38:56.67

実務やってれば分かることなのに

**NAME IS NULL** · 2023/08/02(水) 14:57:10.42

>>418
それはみんなわかってて
具体的にどういうやり方がいいのかという話だろ

**NAME IS NULL** · 2023/08/02(水) 16:07:55.30

販売管理の実務やってる奴なんて実際いないんだろ
いるなら具体例出すだろうしでないのが何よりの証拠

**NAME IS NULL** · 2023/08/02(水) 16:15:58.25

適用日があるなら世代はいらないんじゃねって話かね？

**NAME IS NULL** · 2023/08/03(木) 09:58:26.73

そもそも適用時に応じて世代ってなんぞ？

**NAME IS NULL** · 2023/08/03(木) 10:00:46.36

ごめん、思い切りミスった
「適用日に応じた世代ってなんぞ？」だったw

価格が変わる毎にテーブル作るのは非効率に感じるし、
SELECTのSQLがどうなるかわからん

**NAME IS NULL** · 2023/08/03(木) 10:26:49.29

世代番号列を作るってことじゃないの？
必要になるシーンが浮かばないけど

**NAME IS NULL** · 2023/08/03(木) 11:34:09.40

ある商品Aがある。通常の単価は100円
10/5は特売日なので80円、それとは別に10/11～15は90円
みたいなケースだと
10/1～4　100円
10/5　80円
10/6～10　100円
10/11～15　90円
10/16～　100円
みたいになるけどそれぞれの期間を世代とかいってるのか100円でないものだけ世代とか言ってるか意味不明なんだよな
単純に適用日で管理といえばいいと思ってる

**NAME IS NULL** · 2023/08/03(木) 11:50:48.91

後者を世代と言ってるなら要件定義ミスの原因になりかねないほど日本語が不自由だし、前者でも後者でもやはりいらない。

**NAME IS NULL** · 2023/08/03(木) 13:16:26.10

価格テーブル作って
ID、価格、開始日、終了日
にしたら世代管理にならないか？って思ったら、>>409に書かれてたw

ほんと言うだけ言って具体例出さないよな

**NAME IS NULL** · 2023/08/03(木) 15:29:58.52

NULLのカラムを検索結果から除外するSQLなら、そもそもインデックススキャンになるSQLならインデックススキャンになるだろw

**NAME IS NULL** · 2023/08/03(木) 15:33:17.05

だいたい日付の開始日が設定されていないような状態なら、他のステータス項目で判断できるようなデータモデルじゃないと、クソみたいなSQLだらけになる。

**NAME IS NULL** · 2023/08/03(木) 15:41:34.40

>>428
それ俺の知ってる言葉の意味と違うから要件定義ミスになっちゃうという話にしか聞こえないぞ
一般的な意味とは違っても現場現場で定着してる語義ってあるからな
自分の知ってる意味と違うならそれを明確化させればいいだけ

**NAME IS NULL** · 2023/08/03(木) 15:43:58.47

>>429
そういうのを「世代」や「世代管理」とは呼ばないというのが
>>427-428の言いたいことなんじゃないかな

**NAME IS NULL** · 2023/08/03(木) 19:07:02.41

じゃ、その言いたいことを説明すればいいだけじゃん
他の人は例を出してるのになぜ出さない？

**NAME IS NULL** · 2023/08/03(木) 19:16:30.28

言葉の問題とかどうでもいいから今回の価格の話だけすればいいと思うんだよな

**NAME IS NULL** · 2023/08/03(木) 21:23:42.18

>>418がしょうもないこと言うから脱線したけど、元々の相談者の悩みは解決したんじゃないか

**NAME IS NULL** · 2023/08/03(木) 21:47:21.74

夏休みだとこの程度なんだろうな

**NAME IS NULL** · 2023/08/03(木) 22:01:59.09

データベーススペシャリスト試験は国語力が試されるからそんなもんだろう。
問題文に書いてあることを読み落としたり逆に書いてない行間を読んだりしたら解けない。

**NAME IS NULL** · 2023/08/03(木) 22:12:43.51

急にこういう訳わからん事言うのも夏休みだからかなw

**NAME IS NULL** · 2023/08/03(木) 22:25:05.03

実務やってれば分かるって人は理論とか嫌いだしね

**NAME IS NULL** · 2023/08/03(木) 22:29:26.60

DBスペシャリストは実践的なDB設計には役立たないんだよ
この1週間の一連の流れだけ見てもわかるよね

**NAME IS NULL** · 2023/08/03(木) 22:37:38.54

>この1週間の一連の流れだけ見てもわかるよね

KDD爺の「俺が正しい。根拠は言えないけど。」が多かったね。
実務やってりゃ分かる「世代」って結局何だったのか。

**NAME IS NULL** · 2023/08/03(木) 22:42:51.15

>>440
リレーショナルセオリーだけじゃ主キーさえ選べない

**NAME IS NULL** · 2023/08/03(木) 22:49:53.56

>>443
そりゃセオリーだけじゃどんなデータを格納するかすら決められないがそういうのとは違う話？

**NAME IS NULL** · 2023/08/03(木) 23:22:21.06

>>441
>DBスペシャリストは実践的なDB設計には役立たないんだよ

試験受かった人が自分の設計力のなさを自虐しているのならわかるがそうでないならかなり恥ずかしいな。

**NAME IS NULL** · 2023/08/03(木) 23:25:47.44

NULLに何かしらの意味を定義するやつは永久に消えないんだろうな。

自分が作っているシステムの列値がNULLだと、業務的にはこういう状態だとするのは、愚かとしか言いようがない。

インデックスにNULLが含まれないのは、NULLを検索することがイレギュラーだとされているからな。

**NAME IS NULL** · 2023/08/03(木) 23:40:39.58

MySQLだとNULLにもインデックス使えるみたいですよ

**NAME IS NULL** · 2023/08/04(金) 09:32:08.09

実務やってりゃ分かるって、昭和じじいの考え方そのものだよね
言語化できないから、それっぽい言葉を使って誤魔化してるだけで
実際は自分もよくわかってないっていうｗ

**NAME IS NULL** · 2023/08/04(金) 14:02:01.62

職場で叱責されたからってここで八つ当たりはやめよう

**NAME IS NULL** · 2023/08/04(金) 21:36:10.06

実務やってりゃ分かるって言ってるのはその実務の現場でシステム開発してるんだろうな。
DB専門家でもないから理論の話や試験資格なんかには激しいアレルギー反応を起こす。

**NAME IS NULL** · 2023/08/04(金) 21:37:52.91

もう何言いたいのかわかんなくなってきてるぞwww

**NAME IS NULL** · 2023/08/04(金) 22:02:39.80

オレは理論に詳しいんだ、まで読んだ

**NAME IS NULL** · 2023/08/04(金) 22:26:36.79

理論に自信があると言っている人は議論ができるが実務言ってる人が議論を拒否する。

**NAME IS NULL** · 2023/08/04(金) 22:31:57.36

その理論と資格で上司や客とやり合ってみてください

きっと賞賛されますよ
さ、頑張れ！

**NAME IS NULL** · 2023/08/04(金) 22:36:15.71

>>453
そいつ理論も全く詳しくないのに
なぜそんなにイキリたがるのか不思議

**NAME IS NULL** · 2023/08/04(金) 22:37:09.24

あ、アンカ間違えたわ
そいつ→君

**NAME IS NULL** · 2023/08/04(金) 22:38:13.39

>>446
NULLがもともと持ってる意味がある
ボラクル君の大好きなコッド博士も明言してるしSQL標準でも明記されてるよ
終了日がまだ決まってない場合にNULLを入れるのは
NULLがもともと持ってる意味をそのまま使ってるだけ

インデックスにNULLを含めるかどうかはSQL標準的には実装依存ではあるけど
現実的にはSQL標準で定義されてる操作を効率的にやろうとすればインデックスに含めない選択肢はない
だからオラクルもPostgresも間違いを認めて結局修正してる

**NAME IS NULL** · 2023/08/04(金) 22:39:04.45

煽って教えてもらいたいだけでしょ

**NAME IS NULL** · 2023/08/04(金) 22:40:48.57

判ってるから、誰も教えてあげないんだろう

**NAME IS NULL** · 2023/08/04(金) 22:51:32.25

根拠を挙げて議論するというのは仕事でもふつうにやってることだが。
なんで、「実務やってるなら分かる」でそれ以上説明しようとせずにごり押ししようとするのが理解できん。