好きなSQL嫌いなSQL

AsakusaFW & Tsurugi Advent Calendar 2021の15日目です。

TsurugiDBはpostgreSQL互換のインターフェースを持ちますが独自で標準に準拠したSQL処理も行います。日々SQLの実装と格闘している筆者がSQLの機能の中で好きなものと嫌いなもののランキングを発表します(偏見に基づいた個人の見解です)。

好きなSQL

1位 CREATE TABLE

DDLを発行するときの世界をつくる感じが好きです。これから実現されようとしてるデータやアプリケーションを考えてその土台を整えている感じ。ただ、DBMS開発者としては、テーブル定義の情報はコンポーネントに跨って必要とされるうえ、キャッシュを含めて取り扱いが大変。いろいろな機能がテーブル定義へ積み込まれる傾向があったり、ロールバック可能にするのかなど実装上設計上の課題も多いところ。

2位 SELECT

データ処理を抽象化してパワフルな操作を表現するSQLの象徴的な存在です。SELECT文は間違いなくSQL界のスター。SQL実行エンジン開発の7割以上はSELECT文のリッチな機能の実現と高性能化に費やされているといっていいでしょう。SELECTも書き始めの高揚感がある一方で、その読みやすさには定評(?)があり、既存の巨大クエリに遭遇したときの絶望感もあります。「英語と同じ語順にして読みやすく」って本当にカスタマーが必要としていたものなのかな・・・。

3位 CREATE INDEX

性能ほしいですよね。インデックス強いですよね。遅いクエリがインデックス追加で高速になった時はテンションあがりますね。表面上はシンプルなのに裏側でB-treeとかmasstreeとか頑張ってくれるのありがたいですね。でも最近は列指向DBなども増えてきてユーザーに定義列を選ばせなかったり、CREATE INDEX文は微妙に存在感が薄れている感も・・・。

嫌いなSQL

1位 NULL

NULLは便利な必要悪みたいなものと思っています。データを集めても必ず欠けるものありますよね。NULLがないとレコードが挿入できないですね。でもアプリから使う時に「なぜここNULLなんだ」と困りますね。人間って勝手ですね。DBMS内部でもif (nullable)であちこち分岐してしまうのが性能的にもコードの見た目にもイマイチです。

2位 UPDATE

レコード見つけて更新します、更新なんて簡単ですよという羊の皮をかぶっているのがUPDATE文です。油断するとキーなんて存在を無視して大量のレコード更新を実行してしまう。もう少しシンプルにピンポイントにレコードを指定して更新する書き方があったらなあ、と思います。UPDATEはREAD前提になってしまうので、純粋な上書きWRITEができなくてトランザクション処理に余計な負担をかけるところも気になります。

3位 ALTER TABLE

作ってしまったけど、変えなければならない。打ちたくないけど打たなければならない・・・。そんな重苦しい雰囲気を感じます。DBMSの変更計画を立てて運用停止して恐る恐る発行して祈る、まるでビルの土台を移動する大規模工事のような重みがDB管理者の判断と操作に任される瞬間です。あまりお近づきになりたくないところ。DBMS開発者としても既存のデータに関連する変更はいろいろと大変なので、DROPしてCREATEで済めばなあと思う日々です。(TsurugiDBではまだ未実装なのでどうなるか分かりませんが・・・)