t_wの輪郭

https://speakerdeck.com/recruitengineers/shi-jian-detabesushe-ji

Class Table Inheritance
クラステーブル継承

Concrete Class Inheritance
具象クラス継承

Single Table Inheritance
単一テーブル継承

実体-属性-値モデル

オブジェクト指向的な発想では、データベースにpersonというテーブルがあったときに、personテーブルのカラムとしてnameを持つことになる。そして、ソフトウェア開発の現場ではしばしば「personはnameを持つ」と呼ぶ。したがって「nameはpersonに属する」と認知されている。

しかし、発想を逆転すると、「あるpersonの個体（つまりレコード）は、あるnameの個体の集合に属する」という見方ができる。具体的かつ日本語にすれば、「personの個体であるところの田中さんは、nameの個体であるところの"田中"という集合に属している」。

上記をテーブルにするならば、personテーブル、nameテーブル、

ソフトウェア開発ではしばしば、「テーブル間の関係が1対1であると思われていたが、実は1対多だった」あるいは、「実は多対多だった」ということが発生する。実際、多くのプログラマーの認知に反して、人と名前の関係は1対1ではない。

接触元　『SQLアンチパターン 幻の第26章「とりあえず削除フラグ」』

https://speakerdeck.com/gennei/lu-li-detateburutonoxiang-kihe-ifang-phperkaigi2024

繰り返しイベントのテーブル設計について調べていたら、『設計者の発言 業務システム開発とデータモデリングに関する語り』を見つけた。

参考になる。

https://dbconcept.hatenablog.com/

https://note.com/fnwiya/n/n3dacba99c54a

テーブル設計技法のイベントソーシングを試すぞ！！

https://www.wantedly.com/companies/lapras/post_articles/349385

　テーブル設計がつらすぎる。DBの経験が薄い＆DBから長らく離れていた せいだろう。プログラムだったら感覚でなんとなくなんかいい感じにできてしまうが、経験のないやつはどうしようもない。
　PlantUMLでER図を書いて、壁打ちしたほうがよさそうだ。設計資料も残るのでその意味でも利点がある。

だいぶめんどくさくなってきたな。乗り換えるとなると、DBのテーブル設計もやり直さないといけない。いっそ作り直したほうが楽ではないかと思えてくる。

部分的にjsStoreに置き換えるとかでもいいのかもしれない。