エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
テーブル操作と業務ロジックの連動制御 - 設計者の発言
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
テーブル操作と業務ロジックの連動制御 - 設計者の発言
テーブルに依存する業務ロジック(ビジネスルール)であれば、アプリから独立した「テーブルの拡張定義... テーブルに依存する業務ロジック(ビジネスルール)であれば、アプリから独立した「テーブルの拡張定義」として一元的に管理されなければいけない。そしてそれは、アプリによるテーブル操作に応じて暗黙的に呼び出され、アプリと変数域を共有しつつ実行されなければいけない。何のためか。アプリをうすっぺらにして、開発・保守の効率を高めるためだ。前回記事でそのように説明した。 では、テーブルに依存する業務ロジックであれば、アプリによってテーブル操作がなされたら必ず実行されるべきかというと、じつはそうではない。テーブル操作と業務ロジックを連動させるかどうかは、システム内部のアプリによって選択可能でなければいけない。両者を連動させたいことも、そうでないこともあるからだ。 このことに関係するのだが、RDBMSによって提供される外部キー制約やカスケードオプションのような「気の利いた機構」を、私はよほどのことがない限り使