システム開発をしていて、RDBMSを扱っていると、そのRDBMSのテーブル定義をどのように管理するかということについて考えることがある。例えばそのシステムが所謂Web系のシステムであり、更にRuby on Railsを用いて開発されているとする。Ruby on RailsにはデータベースのO/RマッパーとしてActive Recordがあり、データベースマイグレーションの機能も持っている。そのため、通常であれば付随しているマイグレーション機構に則る形で、マイグレーションファイルも管理していくことだろう。おそらくそのマイグレーションファイルはRubyで記述されており、リポジトリにコミットすることだろう。もしこれがDjangoであったとしても同じことが言える。
では今回なぜこのような事を考えているのかというと、システムの進化の方向によってはこのやり方から逸脱するようなケースを踏んだことがきっかけだった。具体的にはどのようなケースかというとNewSQLへの乗り換えである。システムの進化や社会からのシステムの要求により、システムがRDBMSへ要求することが増えたり厳しくなっている。例えば大規模なデータを抱えながら、高速なデータ問い合わせを行うことなどだ。他にもある。これまでもシャーディングやその他さまざまな技術を用いてRDBMSを利用してきたが、それがそろそろ限界に至ることもあり、今では他の様々なアプローチのデータベースが実装されている。NewSQLは特定の製品を指す言葉ではない。SQLとの互換があり、更に様々な特徴や機能を兼ね備えている。「SQLとの互換がある」は、RDBMSを扱っている側からするととても嬉しいことだ。
自分達のプロダクトが成長し多くのデータを抱えた時、NewSQL製品に乗り換えることでパフォーマンスを含めたさまざまな問題を一気に解決できるのであれば、こんなに嬉しいことはない。だが実際にはそんなにうまい話はない。「SQLとの互換」といってもどのデータベースベンダーのことなのかというものがある。データベースによってSQLには若干の違いがある。また特定のデータベースと互換があると謳っていても完全に互換があるとは限らない。インデックスの付け方やALTERの仕方で若干の違いがあったりする。特にマイグレーションファイルで問題が出るものは厄介だ。正しいSQLが分かったとしてもO/RマッパーがそのSQLを吐くために、O/Rマッパーをかなり深い所まで理解すること要求される。SQLは分かっているのに。これは面倒だ。こうなると最初からSQLでマイグレーションファイルを管理していったほうが良かったのではないかと考えたりする。実際に仕事で使う場合であれば、チームの理解を得る必要があるため現実的ではないが、頭の片隅に置いておこうと思う。