Q. データ肥大化によるパフォーマンスの悪化は、アーカイブテーブルであれば避けられますか？
A. はい、メインテーブルのパフォーマンス悪化は劇的に避けられます。アーカイブテーブルを使うことで、メインテーブルのインデックスがスリム化され、検索効率が向上します。
また、スキャンの範囲が制限され、書き込み（INSERT/UPDATE）も高速化されます。
ただし、「全期間検索」が重くなることや、データ移動時のトランザクション管理など、システム全体の複雑性は増大します。
テーブルパーティショニングも同様の効果を持つ解決策の一つです。これはデータに「忘却」という規律を持たせることと言えます。

Q. 論理削除の別バージョンとして、削除済みレコード用のテーブルを使う方法はありますか？
A. はい、アーカイブパターンとして知られる方法があります。
これは、削除時にレコードをメインテーブルから削除済み専用のアーカイブテーブルへ移動させるものです。
これにより、メインテーブルが軽量化され、検索パフォーマンスが向上し、型純粋性も保てます。しかし、スキーマ変更時の両テーブル同期や参照整合性の破壊が課題です。
SQL標準には、DBが自動で履歴を管理するTemporal Tablesという機能もあります。この方法はパフォーマンス向上に有効ですが、保守コストやDB製品の選択が伴います。

Q. イベントソーシングを大真面目に採用したDBはありますか？
A. はい、EventStoreDBやDatomicなどがあります。
EventStoreDBは追記のみで更新概念がなく、Datomicはデータベースを不変のデータ構造として扱い、過去の時点へのタイムトラベルが可能です。
これらのDBは、イベントを再生することで究極のデバッグ能力や監査ログの保証、リードモデルの柔軟性を提供します。しかし、学習コストやイベントのバージョニングといった課題もあります。
これらは上書きを制限し、真実の履歴を重視する設計思想を持つデータベースです。

Paranola - Zheanna Erose
youtu.be/HjcQyQYhA7g

引き続き…
garden.asappy.xyz

ラズパイと比べたらお話にならなくて泣く

厳密に言うと、アッパーストラクチャートライアドは大抵、左手は3和音以上、右手は3和音の形になることが多いですが...
まあ、どちらも難しいテンションを脳の負担の少ない楽な方法で弾くためにありますから、考え方も同じようなもんだと思ってます！

なので、その認識であれば健康だとおもいます〜

そう！！！それこそが、あのアッパーストラクチャートライアドの考え方なのだ！！！

私はこの問題について、恐いけど未来も感じている。今まで信じてきた、人間の脳が宿す意識が、夢に見たデータ上の永遠の命-"Digital immortality" へと投影-"Mind Uploading" できるかもしれないから。

でも、このクオリアが解明された未来には、心置きなく精神を機械に投影することができるということになる。
物理的に解明できないことが証明された時には、その精神の投影に意味はないと言われるだろう。哲学的ゾンビの誕生となる。意識は宇宙の特異点であるということになる。
ただ、どちらにせよそれには人間の根源的な意識を失うことへの恐怖が伴うだろうけど。
意識の同一性の問題が解決されていようが、人間の本能からそれを受け入れることは難しいだろう。ただ、テセウスの船のように、漸進的に行うことで意識の連続性を保つことができると言われることもある。