RDBアンチパターン // Speaker DeckPHPカンファレンス2016の資料です http://phpcon.php.gr.jp/2016/
「論理設計」にこだわる利点 - 設計者の発言
業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 １．業務構成 受注登録業務、受注保守業務、受注照会業務 ２．データ構成 受注見出しテーブル、受注明細テーブル ３．機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
