◆◆◆

データベースの取り扱いは、どんな言語からでもやっぱり一苦労する。

メインフレームのcobolからDB2につなぐときのlinkage sectionは何て書いたらいいのかとか、CやVBから接続するときの関数はどう書いたらいいかとか、sqlserverからsqlcmdで抜いたcsvをpostgresqlに放り込むにはどうしたもんかとか。

jdbcでoracleからデータ読み込むけど、awsのauroraとかdb用のec2作ってoracle卒業してもいいんじゃないかってとき、データ移すのたいへんだったりする。

実務ではデータありきで処理を作っていくことのほうが多いんじゃないか。

railsを扱ったときもそうだったけど、今はコードの中にSQLを書いたりしないらしい。
こうすると、どんなデータベースを扱っても方言が出ない気はする。

じゃあSQLなしでレコードを扱う方法はどんなんかなって見てみると、「テーブルにカーソルあてて1件fetch、そこからあとはgetnext、getnext」みたいな感じ。
自分にはあまり直観的じゃないなぁっていうか、IBM製品っぽいまわりくどいやり方でちょっと苦手。

レコードを登録することがコードの一部になっていて、理解が足りてないときに「rake」やると（railsのmakeのこと）、データが全部吹っ飛んで「えー、なんでー」ってなったことがあった。

dockerの永続化領域にデータが入ったDBMSなら、こんな状態はいくらでももとに戻せるし、あまり大したことではない。

データが吹っ飛ぶという恐怖体験は克服できるけど、自前処理のphpを別の言語に切り替えたいって考え始めたとき、やっぱりrailsを選べなかった。railsのドキュメントすら読む気持ちにならなかった。

プログラミングや技術にはパラダイムがある。そういうのは否定しないし、苦手ではあるけど、適応しなきゃとは思う。

MVCとかMTVという考え方を否定はしないけど、IT資産のうち累積されたデータベースやファイルのコストっていうのは、コードやシステムよりも高価で価値があると自分は思っている。

だからrakeでデータが吹っ飛んだときは心底「なんでDBの中全部吹っ飛ばすねん！」ってrailsの動きがまったく納得できなかった。コードがデータを支配しているように感じた。

modelを使うとDBMSをあまり意識しなくていいし、「sql書かなくて済む」というメリットはあるのかもしれないけど、最近はsqlが書けないエンジニアもいて（ひどいときはDBMSを意識してない人もいる）、一緒に仕事すると残念な気持ちになることがある。

特に開発フェーズの最後のほうとか、運用に入ったシステムのパフォーマンスを上げていきたいとき、地味にsqlの書き方を変えたり、インデックスつけてみたり、バッチの構成を変えて対処していくことがある。

そういうドロ臭い作業には、今のプログラミングや技術が対処できる余地は少ないように思う。それは自分がまだ知らないだけで、実は方法や手段があるのかもしれない。

djangoを選んだのは淡い期待をこめてのこと。railsで味わった嫌な記憶はあるけど、気を取り直してデータベース取り扱いやってみたい。