リレーショナルモデルのドメイン設計についての議論

リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

[moro]

採番体系なんて『2000年度以降のデータは先頭がAになる』みたいに変わりうるわけで。まさに『(いま)0-9+な番号だから数値だよね☆』とやって詰む事例があるので、他所が決める値をキーとせず人工キー推奨してます。

[tkawa]

リレーショナルモデルの議論としては正しいと思います。アプリケーションの設計としては別の部分もあるでしょう

[te2u]

ナチュラルキーをユニークキーにしたくないのは、制約が外部環境に依存するから。一意性の保証がシステム外でなされていて、コントロールできないのは怖い。だからそれを保証するための属性(ID)を持たせてる。

[k-holy]

理想は分かるけど、サロゲートキーはその場しのぎと断言されるとなぁ。業務じゃナントカIDとかナントカ番号と呼ばれている物が実はエンティティの識別子として不適切なケースがほとんどだし

[Beyond]

「ドメインが時間とともに激しく変わる」もしくは「実装してみないと問題点が分からない」からこそ、railsのような規約のフレームワーク（サロゲートキーの重視）が必要になってくるんじゃないだろうか。

[tmtms]

"Railsの自動採番されたIDを持つという規約についてもひとこと言っておく。クソであると" / 原理主義の理想世界の話はわかるけど、人の目に触れるものはプライマリキーにしないというのが現実的な解だったりする

[zentarou]

“ユーザー企業が責任をもって自分たちの業務で必要なドメインを管理する必要がある”←これが無理だからみんな苦しんでるんだよね

[indication]

それが正しいのはわかる。わかっている、だから、つらい。

[tmatsuu]

同意。主キーのデータ構造変更することへの億劫さからサロゲートキーへ逃げたくなる気持ちもわからなくもないが、多対多の中間テーブルにIDとかあるとムキーってなるよ。

[nemoba]

Railsの規約というかORMの歴史だね。問題領域外で同一性担保に一番便利なのがidという連番。で、発生のほうが多いWebや、拡張時の取り返しのつかなさを考慮すると、無限に並ぶ連番のほうが、リスクが低いから使われる

[kitokitoki]

“リレーショナルモデルのドメイン設計についての議論”

[progrhyme]

「Railsの自動採番されたIDを持つという規約」は「クソ」と言い切った

[hilapon]

これは後でじっくり読ませてもらおう

[makky55makky55]

"技術的負債には利子が付く。" DBに限らず、まさに!!

[BigFatCat]

"「シーケンスやAUTO_INCREMENTを用いたカラム＝サロゲートキー」という誤解が非常に多いのだが〜」「結論を先に言うと、データベース設計ではそのような〜」

[kbkbkbkb1]

ドメインの設計

[Sampo]

RDBは人類には早すぎたんだ / “漢(オトコ)のコンピュータ道: リレーショナルモデルのドメイン設計についての議論”

[NetPenguin]

物理設計？時にはシステム由来なIDを主キーにしたい。

[rryu]

意味を持つコードを意味ごとに分解・正規化して持ちたいというのは思ったことはあるが、暦みたいに年代によって形式が変わるとか変わり目の混沌とかを扱う地獄を考えるととても採用する気にはなれない。

[rgfx]

DBのバッドノウハウ的に見えるものはだいたい業務を考える人間がそういうことを全く考えない(けども、最小限の工数で対応しないといけない)ため、だろうなあ。表現の問題といえばそうなんだけど。

[tak4hir0]

漢(オトコ)のコンピュータ道: リレーショナルモデルのドメイン設計についての議論

[ghostbass]

斜め読み/ 学籍番号はナチュラルではないし、たとえば電話番号もメールアドレスもナチュラルキーにはなれない気がする

[lp008962]

ほぼ自分用DBに種別＋番号(プログラム側でAutoIncrement)してるけど、桁は勝手に増えるから問題ないのかなぁ。WHERE ID = "種別%"はクエリ遅いだろうけど、規模が塵クラスだから・・・

[tsucchi1022]

ほぼ同意なんだけど、「桁数は本質的に表示の問題」っていうの、学籍番号みたいなのに対しては若干暴論かなぁ、と思う

[dekasasaki]

"意味を持つID" はSQLアンチパターンのジェイウォークに該当する。

[stealthinu]

「意味を持つID問題」では属性と番号を別カラムにして複合キーにしたほうが良いと。複合キーについて『複合キーはリレーショナルモデルでは必須の概念なので、抵抗を感じることなく使うべきである』とも

[HHR]

ドメインモデル設計

[YaSuYuKi]

ナチュラルキーをユニークキーとしない運用は、歴史的な理由でそうできない(キーとされていながら実はキーでない)場合以外ありえない/「ユーザーに見せるキー」はUIの一部なのでデータモデルに入れるべきではないよな

[koyancya]

むしろ、これをやらないで怖くないのだろうか。 -> "ナチュラルキーをユニークキーとして定義するという選択もアリだ"

[nakunaru]

”如何なるフレームワークであっても、リレーショナルデータベースを使う以上はリレーショナルモデルをしっかりと理解した上で使うべきである”

[dekokun]

「表示とデータは分ける」の部分に、感銘を受けた。それがあるべき姿だ！

[matarillo]

RDBを使う人にとっては至極まっとうなことを言っているに過ぎない。RDBを使わない人、使いたくない人、ORMで隠ぺいしてしまう人には受け入れられないのかもしれない。

[kukita]

【#データベース設計】リレーショナルモデルのドメイン設計について。「データの本質を見極める…学籍番号…数値なのだから…数値として表現するべき…表示の問題はアプリケーションに任せるべき」等。自分用メモ。