忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
42  41  40  39  38  36  35  29  34  32  31 
 それまで順調に動いていたシステムが、突然ダウンしました。よくよく調べてみると、データベースの定義に余計なユニーク指定のあるのが原因でした。この手の話は良く聞きますが、何かのヒントを含んでいるように思えます。

 ベテラン技術者の曰く、データベース設計をした担当者は、ユニーク指定の意味が、指定のデータでレコードを一意に特定「できる」ことにあるのではなく、一切の重複データの存在を「許さない」ものであることを、理解していなかった。例えば、請求テーブルがあったとして、取引先と請求日を合わせれば、通常はまずユニークになるものです。しかし、そのようなものにユニーク指定すれば、何かの例外データ(例えば、移行データ)を遭って、たちまちアベンドしてしまいます。何よりも、わざわざユニーク指定する「意味」がありません。同じデータ項目の重複を許さない、そのことを、システムを強制終了させてでも貫徹させなければならない場合こそが、ユニーク属性の出番なわけです。
 話を法律に移して、業務提携の契約書を作る場面を考えます。この場合、取扱商品や営業地域が(放っておいても)現にこうなっている、ということは書く必要がありません。プレゼン資料などに、書きたければ書いても構いませんが、それだけの話です。契約書に書くべきは、取扱商品や営業地域の切り分けをして、(破りたくても)その切り分けは守らなければならない、という場合です。自社の主力である「○○端子」を提携先が扱ってもらっては困る、そのことを、裁判に訴えてでも貫徹させなければならない場合こそが、契約書の出番なわけです。こちらの方は、そうでなくても、契約書が無駄に長くなる以上の不都合はないかも知れませんが。
 言葉を換えれば、「世界がどうなっているか(As-Is)を記述する」ことは、ユニーク指定がそうであるのと同様に、契約書の役割ではありません。「世界がどうあるべきか(To-Be)を宣言する」ことが、ユニーク指定がそうであるのと同様に、契約書の役割です。

拍手[0回]

PR
author : ITS 

COMMENT

ADD YOUR COMMENT

NAME
TITLE
MAIL
URL
COMMENT
PASS
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin