ドメイン名の話 (データベース,SQL)

データベースのドメイン名の話

Transcript

1. ドメインの話 LTDD #15 @tsuda_ahr
2. ドメインというと色々ありますが… 今回のドメインは、www.servername.com 、的なやつじゃないです。
3. 昨年、某DB勉強会のハンズオンで、こんな ER 図を書きましたが
4. 列名の命名方法で質問があったんですね。 なぜ「file_size」なのか。 「Size」じゃないのか？
5. ドメイン(定義域)という考え方がありまして。  列名はオブジェクト指向のプロパティやフィールドとはちょっと違う感じ。  列名 = 型、に近い。  この「型」のようなものを「ドメイン名」と呼ぶ。
6. ドメイン名の利点1: 自然結合  普通に結合 select * from TABLE_A inner join TABLE_B on TABLE_A.key1 = TABLE_B.key1;  こう書ける select * from TABLE_A natural join TABLE_B;
7. つまり  普通の結合の場合は、結合する列の対応を記述しないといけない。  自然結合の場合は、同名の列名は結合の対象と自動で判断する。  記述量が減るので、ちょっと便利。  ただ、自然結合は、同名の列名すべてと JOIN するので使いづらい場合が多い。
8. ドメイン名の利点2: 自然結合を使わない場合でも！  同名の列は「結合の条件となり得る」と判断できる。  逆に、列名が違うもの同士の結合は結合してはならない、という暗黙の了解(=規約)を得るこ とができる。 （オブジェクト指向でいう「型の違う代入」と同等）  こちらの利点が主力。
9. 利点2の場合は、実は別の方法もある  create domain 文 本当にデータ型を作る -- PostgreSQL の例 create domain file_size as numeric(12); create table TABLE_A( key1 as varchar(10), size as file_size ); -- Oracle にはない模様
10. create domain の利点と欠点  型名（ドメイン名）による、列の生成が可能となる。 →命名規約というあやふやなものに依存しなくて済む。  他方、ドメイン名に頼って列名を自在に命名すると、自然結合が効かなくなる。  結合列の是非も列名からだけでは判定できないので、SQLの組立てが難しくなる場合が多い。 （ハンガリアン記法みたいですね）
11. まとめ  列名は、オブジェクト指向プログラミングのようにオブジェクト（=テーブル）単位で ユニークにするのではなく、スキーマ単位，あるいはもっと上位のレベルでユニークに するようにします。  列名は「変数名（プロパティ名）」ではなく、「型名」だと思うようにします。 つまり、同じ列名を持っているものは、みな同じ性質を持っていて、かつ、他のテーブルで 同名の列名がある場合には、その列との結合が可能であるように設計します。  しかし例えば同じ型(?)の列が必要な場合もあるので、そのあたりは臨機応変に。 例）自分の性別と恋愛対象の性別を、同一のテーブルに定義する場合とか。
12. ご清聴ありがとうございました。