|
| 1 | +--- |
| 2 | +title: "データベースと向き合う決意をしてから3年たった" |
| 3 | +date: 2025/11/06 00:00:00 |
| 4 | +postid: a |
| 5 | +tag: |
| 6 | + - 2WaySQL |
| 7 | + - DFD |
| 8 | + - 生成AI |
| 9 | + - エッセー |
| 10 | +category: |
| 11 | + - DB |
| 12 | +thumbnail: /images/2025/20251106a/thumbnail.JPG |
| 13 | +author: 澁川喜規 |
| 14 | +lede: "3年前の秋のブログ週間でデータベースと向き合う決意というエントリーを書きました。3年経ちましたが、多少ベクトルは変わりましたが今も基本的な気持ちは変わっていません。むしろ、「生成AIによって自然言語で気軽に作れるようになった」ことで、SQLの敷居は大きく下がりました。" |
| 15 | +--- |
| 16 | +[秋のブログ週間](/articles/20251031a/)の5本目です。 |
| 17 | + |
| 18 | +3年前の秋のブログ週間で[データベースと向き合う決意](/articles/20221111a/)というエントリーを書きました。3年経ちましたが、多少ベクトルは変わりましたが今も基本的な気持ちは変わっていません。むしろ、「生成AIによって自然言語で気軽に作れるようになった」ことで、SQLの敷居は大きく下がりました。 |
| 19 | + |
| 20 | +# DFDのガイドライン作りを始めた |
| 21 | + |
| 22 | +今年はDFDの本が出ました。5月にブログも書きました。 |
| 23 | + |
| 24 | +* [データフローダイアグラム本の献本をいただきました](/articles/20250501a/) |
| 25 | + |
| 26 | +> 本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気持ちを新たにしました。 |
| 27 | +
|
| 28 | +言ったからにはきちんとやろうということでざっとGoogle Docsで20ページぐらい書いて社内の有識者からコメントもらったりしているところです。年内にはある程度目処をつけたいところです。DFD本の表紙にも「いにしえの技術」と書かれているぐらいなので、オリジナルのものをそのまま使っている人はレアかと思います。だいたい各社の中で独自の進化を遂げたDFDを使っているのではないかと思っています。今のガイドラインも社内のDFDの知見のガイドライン化ですし、他社の人が触れる場合には「どこがオリジナルか」というのを明示するのは大事かな、と思い、 |
| 29 | +DFDの原典とされる本も買って読み始めました。 |
| 30 | + |
| 31 | +<img src="/images/2025/20251106a/IMG_7227.JPG" alt="IMG_7227.JPG" width="1200" height="900" loading="lazy"> |
| 32 | + |
| 33 | +構造化分析の本は初めて読みましたが、自分がこの手の勉強をした、UMLやらオブジェクト指向分析よりも実は筋がいいのでは、と読みながら思ったり。2000年ごろのアジャイルブームはUMLの複雑なモデリングへのアンチテーゼだったと思いますが、あのときにUML（を売りたいベンダー）が否定してきた過去のシンプルな手法に目をもっと向けられていたらなぁ、というのはちょっと思いました。 |
| 34 | + |
| 35 | +あと、この本で強調されていることは「DFDではコントロールの流れは書かない」ということです。これはDFDのガイドラインでも触れていましたが、この特性は2つの点で大事だな、と思いました。 |
| 36 | + |
| 37 | +1つは以前書いた[ReactのDFD](https://future-architect.github.io/articles/20221213a/)がなぜうまくいったのかという点です。コントロールフロー≒手続きは、いわゆる条件式とかループです。これらはDFDの1つ1つのプロセスの中に閉じ込められているものです。一方、今時のウェブフロントエンドは手続きではなく、宣言的に書くという思想で作られています。どちらもコントロールフローを見せない仕組みなので相性が良いのは自然なことだったんだな、と思いました。 |
| 38 | + |
| 39 | +もう1つはコントロールをかかない、そのままソフトウェアに落ちたりしないという点ですね。2000年初頭はCASEツールとかその手のツールで設計することでソフトウェアの自動生成などを行って効率アップ、というのがやたら喧伝されていました。その手のツールからすると、書いてもそこから生成できなければ描くだけ無駄ということで、DFDが2000年代に冷遇された理由はこれだったのかもな、というということです。 |
| 40 | + |
| 41 | +# 2Way SQLを作り始めた |
| 42 | + |
| 43 | +<img src="/images/2025/20251106a/スクリーンショット_2025-11-05_20.09.00.png" alt="スクリーンショット_2025-11-05_20.09.00.png" width="1200" height="912" loading="lazy"> |
| 44 | + |
| 45 | + |
| 46 | +今年ちょくちょく生成AI使ってみた外部発表をしていますが、その題材として作っているのが2Way SQLのライブラリです。Goで作っていますが、ランタイムはGoに引き続き、Pythonとかも実装しようとしています。これも、3年前のエントリーでも作っていると書いていましたが、まあ何度目かのチャレンジ。だいたいこの手のやつは3回ぐらい作って初めて納得いくものができるというのが実感ですが、実際、3回目ぐらいですかね。これまでで一番コード行数は多いかも。5ヶ月ぐらいで11万行ぐらい？ |
| 47 | + |
| 48 | +* [github.com/shibukawa/snapsql](https://github.com/shibukawa/snapsql) |
| 49 | + |
| 50 | +生のSQLに制御コメントを入れることでそのままDBにも投げられるし、アプリケーションコードの中でSQLのテンプレートとしても使える、というのが2Way SQLです。2Way SQL自体はたくさん実装が世の中にはあるのですが、だいたい式言語が組み込まれていて、それがJava依存のライブラリで、Java以外ではマイナーな存在となってしまっています。そこも、Googleの[CEL](https://cel.dev/?hl=ja)を採用することでいろんな言語で使えるようにしたいなと思っているところです。 |
| 51 | + |
| 52 | +* ソースは、SQLもしくは、文芸的プログラミングスタイルのSQLが書かれたMarkdown |
| 53 | +* SQLはユーザーが作るが、レスポンスの型と呼び出しコードは自動生成 |
| 54 | + * BlogPost -> Commentのように、親子関係がある要素群を子スライス（配列）にまとめて返す |
| 55 | +* テスト機能内蔵。テストのレスポンスを使ったモック機能も内蔵 |
| 56 | +* UPDATE/DELETEでWHERE句がない（条件なしで前適用」場合にオプトアウトでエラーチェックを追加 |
| 57 | + |
| 58 | +だいたい、どのライブラリも「クエリービルダー」として生SQLを元にWHERE句の条件を足したり減らしたりしたSQLを組み立てる感じです。だいたいの2Way SQLのライブラリは呼び出すところぐらいですが、Goの[sqlc](https://sqlc.dev)のように、型がしっかりついた関数を生成します。クエリー情報を元にサブクエリとかCTEの中も追いかけて型推論しています。WHERE句の条件でレスポンスが単数になるか複数になるかとかも静的解析しています。 |
| 59 | + |
| 60 | +```go |
| 61 | +// 結果のオブジェクト |
| 62 | +type BoardListResult struct { |
| 63 | + ID int `json:"id"` |
| 64 | + Name string `json:"name"` |
| 65 | + Status string `json:"status"` |
| 66 | + ArchivedAt *time.Time `json:"archived_at"` |
| 67 | + CreatedAt time.Time `json:"created_at"` |
| 68 | + UpdatedAt time.Time `json:"updated_at"` |
| 69 | +} |
| 70 | + |
| 71 | +// 生成される関数。クエリーの解析結果でレスポンスは変わる |
| 72 | +// * WHERE句が主キー指定で1要素しか返らないことが明確なら構造体そのまま |
| 73 | +// * レスポンスが複数レコードになるならrange over func |
| 74 | +// * returningがないupdate/insert/deleteならsql.Result |
| 75 | +func BoardList(ctx context.Context, executor snapsqlgo.DBExecutor, opts ...snapsqlgo.FuncOpt) iter.Seq2[*BoardListResult, error] { |
| 76 | +} |
| 77 | +``` |
| 78 | + |
| 79 | +トランザクションは隠さないようにしており、2つ目の引数は`sql.Conn`か`sql.DB`, `sql.Tx`何でも受けられるようにしています。3つめ以降はテンプレートにパラメータがあればそれが入り、型安全な関数となっています。 |
| 80 | + |
| 81 | +他にも[Playwright Lightnings #1](https://playwrightnings.connpass.com/event/340591/)で発表した、E2EテストのFixtureやリクエスト後のDBの状態をテストするツールである[github.com/shibukawa/dbtestify](https://github.com/shibukawa/dbtestify)の機能も取り込み、アプリケーションコードを実装しなくてもSQLだけでユニットテストできる機能なども入っています。このテストの期待されるレスポンスをモックとして返せるようにもしています。「モックを使うと実装とずれても気づけない」という問題があったりしますが、その問題を解消できるかな、と。 |
| 82 | + |
| 83 | +このツールでやっているのは、SQLをトークン分割して構文解析をしてASTを組み立てて、エラーチェックなどをしつつシンプルな命令列に変換してから、最適化を行なって最終的にGoなどのコードを生成する、という動きをします。生成時に文字列結合（`CONCAT`, `||`）、キャスト（`CAST( AS type)`, `::type`）や日付関数などは生成先に合わせて吸収するとかもしてます。まあコンパイラですね。パーサコンビネータから自作してます。ツール自体は結構なロジックの量になっていますが、静的なコードを生成するようにしており、アプリケーションが太らないようにランタイムの依存はほとんどないという思想でやっています。最後のコード生成部分はなるべく薄くしているので、いろんな言語に対応させたいです。 |
| 84 | + |
| 85 | +サンプルコードを作って動かしてみたりしていますが、Goに関しては大体できてきたかなというところです。ドキュメントも昨日、今日でだいぶブラッシュアップしました。生成AIにお願いすると無い機能まであると説明を書き出すのでなかなか大変ですね。 |
| 86 | + |
| 87 | +実際にプロジェクトで使えるものを、という意識で作っていますが作ること自体が勉強になりますね。DBMSごとに書けるSQLの違いとかを意識することになりますし。生成AIにきくとぱっとまとめを作ってくれるけど間違っていることがあるのでまた調べますし。昔は使えなかったけど今は使えるSQLiteの`RETURNING`とかそういう感じで。 |
| 88 | + |
| 89 | +# 次のステップ |
| 90 | + |
| 91 | +だいぶデータベースへの苦手意識も減りデータベースのモデルの議論も積極的に行えるようになってきました。 |
| 92 | + |
| 93 | +2Way SQLも「しっかりしたのを作りたい」というのをずっと思っていたところ、生成AIが重い腰を上げてくれてパッと走り出すことができました。この手の盆栽的な目標があると、生成AIの無料枠が降ってきたときに「お、機能追加するぞ！」というネタになっていいですね。ぼちぼち、Python、Java、TypeScriptあたりのコード生成は追加していこうと思っています。Pythonはasyncioにきっちり対応（むしろそれ以外サポートしない）勢いでやろうかと思っています。 |
| 94 | + |
| 95 | +開発環境の変化、生成AI活用という点で、GitHubやGitLabでプレビューしやすくて生成AIフレンドリーなツール群、というのが今後は求められていく流れは変わらないと思います。生成AIは同じ入力に対して同じ結果を確実に返すのは苦手ですし、そこは何かしらのツールが必要です。論物変換をきちんとこなせるデータベース系のツールはまだまだ少ないなと思うし、その手のツールは今後も作っていきたいなと思っています。 |
| 96 | + |
| 97 | +物理モデルが作られると概念モデルがメンテされなくて放置される問題とかそういうのをいつか改善できないかな、と思ったりしています。 |
0 commit comments