SQL レビューは必要か？開発者の本音

💡 本記事は Reddit の以下の議論を要約したものです: Do DBAs impose strict requirements for database schema conventions at your org?

背景#

投稿者のチームは新しいマイクロサービスを開発しており、データを SQL テーブルに保存する必要がありました。これらのテーブルはマイクロサービスが完全にオーナーで、データは API 経由でのみ外部に公開されます。投稿者は DBA に「不要な」制約を求められた例を 2 つ挙げ、「将来混乱を招く可能性がある」と述べました。そこで質問は、データベーススキーマに対する厳しい要件は本当に必要なのか、ということになります。

DingBat99999 (30 ⬆)#

何か見落としているかもしれませんが、あなたの DBA が求めたものはどれも理不尽には見えません。

制約については、私の経験上、アプリケーション側で強制するか、データベース側で強制するかという議論が必ずどこかで起きます。そこに過去の判断があったのでは？

シャツのサイズは実装依存で動的だと DBA に伝えれば、向こうも制約を求める理由を失います。それ以外は YAGNI です。

💬返信

データベースで enum 制約を強制するのは良いプラクティスですし、有能な DBA と仕事ができているのは幸運です。永続化レイヤーでの厳格なチェックは、システムにゴミが入るのを防ぐ最も確実な手段です。

ccb621 (12 ⬆)#

そのエネルギーをすべて使って、DBA になぜこの変更が大事なのかを聞いてみてください。まだガイドが無いなら、将来のチームが同じ苦労をしないようにガイドを一緒に作るのも手です。

表面的には細かい指摘に見えるかもしれませんが、その下にはこのレベルのレビューを正当化するだけの苦労譚があるかもしれません。

nutrecht (7 ⬆)#

DB スキーマに守るべき標準があるのは、まったく普通だと思います。私もそういう現場を見てきました。同時に、開発者が好き勝手やった結果のカオスも見てきたので、DBA を責める気にもなりません。

なので、enum も命名も、どちらも私には理にかなって聞こえます。DB の enum 制約の利点は、ソフトを壊すような「壊れたデータ」が決して入り込まないことです。テスト用 DB にテスターが直接データを差し込んでいる現場を扱ったことがありますが、それは本当に厄介でした。

両陣営に良い議論があります。個人的にはこれに対してまったく戦うつもりはありません。とくに、いずれその DBA チームの助けが必要になるはずですから。

それと、Java/Spring 開発者として一言: スキーマファーストで仕事しましょう。「Spring のせいで」スキーマを変える必要がある、と感じたなら、たいてい別のところで何かが間違っています。

ViperRT10Matt (6 ⬆)#

うちの DBA はこういう介入はしません。彼らは開発者から渡されたものをリリースし、運用するだけです。スキーマやテーブル設計の変更を求める場面は、車のスタビリティコントロールのようなもの — 極端な状況で本当に危険なときだけ介入します。

AdrianC9 (3 ⬆)#

私は中規模/大規模のテック企業で働いていて、データベース変更をレビューする「DBA」はいます (伝統的な DBA とは違うかもしれません)。ただ標準のほとんどは Wiki に書かれていて、DB 変更を出す前に読むことになっています。なので普通は何を求められるか分かります。例として、テーブルは単数形で命名する必要があり (例: 「tshirt」)、これはまさに投稿者の話に出てきた理由のためです。こうすれば ORM が物事をきれいにマップできます。

DB 制約については、多くの DBA はこれを好みます。自分の領域での統制力が増すからです。個人的には、ビジネスロジックと言えるものを DB に放り込むのは理想とは言えず、将来的に問題を生む可能性があると思います。とはいえ、それほど大きな問題ではなく、衝突で壊れたときに「ほら、この要件があったでしょ」と指せばよいだけです。

nderflow (2 ⬆)#

特にカラム制約は重要です。すでにあったカラム制約を無効化したせいで顧客を数万人失い、数百万を失った企業を見たことがあります。

データベースが整合性ルールを強制できることは、モダンなリレーショナルデータベースの美点の 1 つです。

check-himu (2 ⬆)#

複数形の命名規約はうちも従っていて、強い意見はとくにありません。ただ経験から言うと、DB に制約を強制するのは極めて有用です。コードの変更には常にバグの可能性があり、意図しないデータが通り抜けることがあります。DB の最終チェックがそれを防ぎ、後でデータ修正をする羽目になるのを避けてくれます。

db-master (2 ⬆)#

ある程度の一貫性を強制するのは一般的な実践です。組織全体で同じ ID フォーマット、姓名のフォーマットなどに合意できれば、何時間も節約できます。

ちなみに、CI/CD でスキーマの一貫性を強制する GitHub SQL Review Action のようなツールもあります。

SQL レビューに関する私たちの見解#

Bytebase は組み込みの SQL レビュー機能を備え、スキーマ変更プロセスで問題を検査できるようカスタマイズ可能です。開発者のワークフローに馴染ませるために、SQL レビューを GitHub に統合し、GitHub のリポジトリで SQL スクリプトを管理しながら SQL レビューもそこで行えるようにしました。これにより複数ツール間の行き来が無くなり、何より SQL レビューをデプロイ段階ではなく PR 段階で行えるようになります。

そうは言いつつ、データベーススキーマ変更については助言はシンプルです: 聞かないこと。DBA がそう言うなら、やるだけ！

最後にもう一度 — 本記事はあくまでこの議論の要約です。コメント欄でぶつかり合うベストプラクティスとアイデアの数々を、ぜひそちらでもご覧ください ⚡️。