ここはかなり本質的な論点です。
普通の小説論だと、
登場人物が増える
↓
物語が複雑になる
で終わります。
しかしDB設計との対応で考えると、
登場人物数
≠
物語量
です。
むしろ、
登場人物数
↓
テーブル数
↓
関係数
↓
機能数
↓
物語量
という構造になります。
レベル1: 1テーブル小説
極端な例。
Sanshiro
しかない。
すると、
三四郎が考える
三四郎が悩む
三四郎が決意する
しか起きない。
JOIN相手がいない。
これは内面小説に近い。
DB的には
SELECT *
FROM Sanshiro
だけ。
レベル2: 2テーブル小説
Sanshiro
Mineko
だけ。
すると
出会う
惹かれる
迷う
別れる
が作れる。
DB的には
SELECT *
FROM Sanshiro
JOIN Mineko
だけ。
だから恋愛小説の原型は
2テーブル構造
とも言える。
レベル3: 3テーブル小説
三四郎なら
Sanshiro
Mineko
Hirota
になる。
すると
恋愛
+
思想
が混じる。
こんな機能が生まれる。
encounter_mineko()
consult_hirota()
compare_mineko_and_hirota()
重要なのは
三四郎⇔美禰子
だけでなく
三四郎⇔広田
が増えること。
さらに
広田の思想
↓
三四郎の恋愛解釈に影響
も起きる。
テーブル追加は機能追加
Webアプリも同じです。
例えば
Users
しかなければ、
ログイン
だけ。
そこへ
Posts
を追加。
すると
投稿
閲覧
が生まれる。
さらに
Comments
を追加。
すると
返信
議論
通知
が発生する。
小説も同じ。
新人物追加とは、
新キャラ投入
ではなく
新機能モジュール追加
です。
本当に重要なのは人物数ではない
ここが面白い。
例えば
A
B
C
D
E
の5人がいる。
しかし全員が主人公としか関わらない。
つまり
A-B
A-C
A-D
A-E
しかない。
これはスター型構造。
B
|
D --A-- C
|
E
実はあまり複雑にならない。
長編はJOIN網が増える
本当に複雑な小説は、
A-B
A-C
B-C
C-D
D-E
A-E
B-D
...
となる。
例えば『源氏物語』。
人物数も多いが、
さらに
誰と誰が結びつくか
が膨大。
DB的には
テーブル数
×
リレーション数
``
が巨大。
三四郎は意外と小規模DB
三四郎を見直すと、
主要テーブルは実は少ない。
Sanshiro
Mineko
Hirota
Yojiro
Nonomiya
程度。
だから長編というより、
かなり整理された設計になっている。
漱石は
大量キャラ投入型
ではなく、
少数高密度接続型
の設計者とも言える。
あなたの理論をさらに発展させる
私はむしろ、
登場人物数を見るより、
各人物テーブルが提供するAPIを見る方が重要だと思います。
例えば
Mineko
は
attract()
confuse()
distance()
を提供する。
Hirota
は
advise()
observe()
question()
を提供する。
つまり人物とは
テーブル
+
API群
である。
そして物語とは
Sanshiro.attract(Mineko)
Sanshiro.question(Hirota)
Hirota.observe(Mineko)
Sanshiro.confuse()
の実行ログになる。
ここから導ける仮説は面白いです。
良い長編小説は
登場人物が多い作品
ではなく、
APIを持つテーブルが多く、
その組み合わせが多い作品
である。
つまり設計指標としては、
人物数
より
関係数(Relationship)
または
API呼び出し数
の方が重要かもしれません。
Webアプリでいうなら、
テーブル数
より
ユースケース数
``
がシステム規模を決めるのに近いですね。