マイグレーションしないRDBMS

README.md マイグレーションしないRDBMSが欲しい! 課題 PostgreSQLなどの既存のRDBMSはスキーマを持つ。スキーマがあることは良いことだが、このスキーマのライフサイクルはアプリケーションコードのライフサイクルと乖離しがちで、結果として以下のような問題が発生する。 特に自動化をしない場合はマイグレーションをデプロイとは別に行う必要が発生する。これにより、 シンプルに作業が面倒。 承認フローが追加で必要になる。または、デプロイはレビューの管理下に置かれているのにマイグレーション側が適切に管理されないなどのミスマッチが起きる。 マイグレーション忘れ、マイグレーションのリバート忘れのリスクがある。 異なるバージョンのアプリケーションは同時に存在できるがスキーマは同時に存在できない。これにより、 ある種のスキーマ変更はローリングデプロイ環境下では実質的に実行できない。 (テー

[koba789]

結局 RDBMS であってもデータの物理表現から自由になれていないのが悪いということなので、パフォーマンスペナルティを無視すれば VIEW などを駆使して実現できそうな気もするが、本当の困りごとはそこではない気もする

[findup]

それで一時期MongoとかのNoSQLとかがかなり流行ったよね。RDBMSは時代遅れって叩かれて。でも結局揺り戻しが来たってことは何か理由があるわけで。入れ物（スキーマ）に柔軟性持たせすぎると収拾付かなくなるんだよなあ。

[khtno73]

内製化とCI/CDの進化で開発スピードが上がってRDBMSの変更が大変なのがボトルネックになるのわかるが、それは受容するべき、と思ってるのよな。スキーマレスやこのアイデアは面白いけど、後のデータ分析きつくない？

[Wafer]

悪名高いMongoDBは複数のスキーマを同時に持つことをjsonで表現しようとしたといえなくもない/パーティションなしで数億レコードを持つDBは個人的にはその時点で設計ミスと断じたい

[snowcrush]

本質的にはMongoDBのようなスキーマレスのNoSQLとアプリケーションレイヤーでのスキーマ管理の組み合わせと同質に見える。

[yosio_ism]

面白いなーとは思うけど、解決できる問題と新しく発生する問題を天秤にかけて、利が勝つのかなあ？というのが予想しにくい。

[kompiro]

Salesforce ってこんな感じじゃなかったっけ

[diveintounlimit]

NoSQLブームの時と同じ事言ってる気がする

[strawberryhunter]

複数スキーマにデータを保存するのかviewで見かけを変えるのか、いずれもスキーマ間で互換性を確保する必要があるので変更に制約を設けて、データの翻訳を自動化する必要がありそう。すぐに破綻すると思う。

[circled]

最近はPostgreSQLもMySQLもjson/jsonb型のカラムが持てるから、そこで何とか頑張れば？と思うところ。

[kamm]

複雑で事故りそう

[zentarou]

とはいえスキーマ変更は機能開発とは別ブランチでやってさっさとマージ＆デプロイしちゃうからなぁ

[Shinwiki]

あとで

[m50747]

これは同じ悩みがある。DB設計をしっかりする前提と開発環境でしっかりテストしておけば変更マイグレーションは不要にできる。マイグレーション忘れは論外。しかし数億のデータがあるスキーマの場合どうするのだろう

[everybodyelse]

スキーマを複数持つのはいいけど、それはそれで複数を管理し続けるコストが発生するので、それを嫌って結局は単一のスキーマに収束しそうな気もする。アプリケーション側でも複数のスキーマを考慮しないといけないし