データベース側にビジネスロジックを持たせるべきか否か?

皆さん、あけましておめでとうございます!
暫く更新が滞ってしまいましたが、2023年から月1回でブログをアップしていきたいと思います。

先日、MySQL互換分散データベースであるTiDBの開発・保守サービスを提供しているPingCAPさんと対談する機会をいただきました。

【参考】
https://pingcap.co.jp/

上記Webサイトを見ていただければ分かると思いますが、TiDBの特徴は・・・

・MySQL互換(9割以上)
・分散DB
・コンピュートレイヤとストレージレイヤが分離されており、負荷状況に応じて個別のスケールアップ/スケールアウトが可能
・OLTP処理は勿論、リアルタイム分析も行える(HTAP)
といったところでしょうか。

分散DB自体は以前から存在していましたし、近年、CockroachDBやYugabyteDBなど、PostgreSQL互換のプロダクトは提供されていますが、MySQL互換でエンタープライズで利用できるレベルのものはTiDBしか(今のところ)ありません。
TiDB内部の動作など、今後検証していく予定です。

話を本題に戻しますが、対談の中で「データベース側にビジネスロジックを持たせるべきか否か」という話題がありました。

今回は、この件について書こうと思います。

データベース側に組み込むビジネスロジックとしては、下記が代表的なものとなります。
・ストアドプロシージャ/ファンクション
・テーブルに付与するチェック制約
・テーブルに付与する参照整合性制約

まず、ストアドプロシージャ/ファンクションについて見ていきます。
メリット
1、コンパイル済みのものをコールするため、クエリ解析のためのリソース消費と時間が省ける。また、アプリケーションからの処理を制限できる(SQLインジェクション対策)
2、大量データの処理をDBサーバ上で行えるため、ネットワーク負荷の低減が期待できる。また、DBサーバ上で処理が完結するため高速である

デメリット
1、ストアドプロシージャ/ファンクションを記述する言語は、それぞれのRDBMSによって異なるため、別のデータベースに乗り替える際、改修コストが高くなる
2、アプリケーションの仕様追加・変更時に確認・テストする箇所が増える
3、パフォーマンス調査、障害調査のデバッグ時に確認する箇所が増える
4、沢山のストアドプロシージャ/ファンクションを動作させると、DBサーバの負荷が高くなる

上記メリット/デメリットから、ストアドプロシージャ/ファンクションは、性能を上げたい処理のみに絞って作成する方がよさそうです。
便利だからと言って作り過ぎると、想定外にDBサーバの負荷が高くなったり、別のRDBMSに乗り換えたくても改修コストが大きすぎて、乗り換えできなくなってしまったりします。

続いて、チェック制約と参照整合性制約について見てみます。
メリット
1、チェックのロジックをアプリケーションに組み込まなくて済むため、開発/改修工数の低減が期待できる
2、アプリケーションからはチェックをするためのクエリを発行しなくて済む(処理の簡素化)

デメリット
1、データの更新タイミングで初めてチェックされるため、複数項目の入力チェックには向いていない
2、仕様変更時、DB側への定義変更が必要
3、データベース側でチェック処理が動作するため、クエリの実行速度に影響する場合がある
4、画面設計書、テーブル定義書の両方を確認しないとチェック内容の全貌が把握できないことがある

お買い物サイトなどの会員登録の画面や送付先情報の入力画面で、項目入力後の「確認」ボタンをクリックした際、全ての入力エラーの項目が表示されない(何度も「確認」→入力しなおしが必要)といった経験をされた方もいらっしゃるかと思います。
恐らく、そのようなケースでは、DB側のデータチェックの仕組み(チェック制約や参照整合性制約)を利用しているのではと考えられます。(アプリケーションそのものの作りがイケてないこともありますが・・・)

個人的には、チェック制約や参照整合性制約はDB側に実装するのではなく、アプリケーション側で実装してもらいたい派です。

まとめです。
ビジネスロジックは、処理の都合上(主にパフォーマンス)どうしてもデータベース側に定義しないといけない場合を除いては、アプリケーション側で定義しましょう。

厳選したもののみデータベース側に存在しているのであれば、別のRDBMSに乗り換える際にもそこまでの改修コストは発生しないですし、仕様追加・改修時の影響調査の範囲も狭めることができます。
(当然、別RDBMSに乗り換える際はパフォーマンス問題もついて回りますが、それはまた別の話ということで)

皆さんはどのようにお考えでしょうか?
最後に、2023年が皆様にとって良い一年となりますように。

最近の記事

TOP CTOブログ データベース側にビジネスロジックを持たせるべきか否か?

Recruit 採用情報

Contact お問い合わせ

  購入済みの製品サポートはこちら