第一幕: 創造の混乱

ある日、全知全能を名乗る神様が「世界を創ろう！」と思い立ちました。しかし、神様はデータベース設計初心者のポンコツエンジニアでした。まず最初に「光」を作ろうとしましたが、次のような設計をしてしまいます。

Table: creations
- id: 1
- type: "light"
- light_id: "sunlight-001"
- light_name: "太陽の光"
- description: "ただの光"

神様は自慢げに言いました。
「ほら！光を作ったぞ！完璧じゃろ？」

しかし翌日、「光が明るすぎる」というクレームが入ります。神様が調査しようとすると、light_idがデータベースのあちこちで使われていることに気づきます。さらに、light_idが「太陽の光」以外の月光や星光にも使われていることが発覚。ここで神様は混乱し始めます。

「このlight_idって、一体何の責務を持っているんだ？光の種類？それとも物理的な出力？」

第二幕: データの堆積地獄

神様は次に「地と海」を作りますが、ここでも意味を含んだID設計をしてしまいます。

Table: lands
- id: "earth-001"
- region_id: "land-sea-456"
- region_name: "地と海"
- description: "見た目はいい感じ"

ポンコツ神様は、後から「海」を追加したくなりましたが、region_idが陸地と海の両方を含む形になっており、明確な境界を持たない設計のせいでエラーが続出しました。

その上、region_idを参照していた別のテーブル（例えば動物や植物を管理するテーブル）では、一部の動物が「海」と「陸地」の両方に存在していることが矛盾する結果に。「魚」がなぜか「山」に配置される事件も発生。

神様は頭を抱えながらこう呟きます。
「データが一貫してない…おかしいな…全部IDで管理してるのに…」

第三幕: データベースの崩壊

最終的に神様は人間を作ります。

Table: humans
- id: "human-adam-001"
- type: "male"
- dna_code: "12345-abcde"
- related_land_id: "earth-001"

この設計もまた混乱を生みました。idに「人間の名前」「性別」「属性情報」が全部詰め込まれており、後から「イブ」を追加した際にrelated_land_idが地と海の混乱したデータ構造に影響され、人間同士の関連付けができなくなる事態に。最終的にシステム全体がパンクし、神様は世界のリセットボタンを押してしまいます。

解説: 意味を含んだIDデータの問題点

物語の神様が直面した最大の問題は「意味を含んだIDデータ」による混乱です。この設計では以下の課題が発生しました。

属性や責務の分散
- 一つのIDに複数の意味（例: 光の種類、物理的な特性）を持たせたことで、データの一貫性が保てなくなりました。
変更に弱い設計
- 意味を含むIDは、要件変更時に影響範囲が広がりやすく、修正が困難になります。
参照の混乱
- 他のテーブルで意味を含むIDを参照すると、誤解や矛盾が生じる可能性が高くなります。

理想の設計は、IDを単なる一意性を保証する識別子として扱い、属性情報は別のカラムやテーブルで管理することです。例えば、light_idではなく、idを単純な連番にし、光の種類や特性は別カラムとして保持すべきでした。

このように、意味を含んだID設計は、ポンコツ神様のような混乱を招きます。設計をシンプルに保つことが、世界（とデータベース）を平和に保つ秘訣です。