使える論理削除への道(1) それは論理削除の問題なのか - 極北データモデリング
削除フラグ(というか「論理削除を削除フラグだけで実装すること」)批判は何度も見てきたが PostgreSQLアンチパターン これ見るともはや論理削除自体が闇扱いになってしまったようだ。 闇だろうと何だろうと論理削除(というドリルが提供する穴)は要件の実装に必要なので、このへんの議論はあまりまじめに追ってこなかった。 いつだったか「削除フラグはバグの温床だからやめろ」という主張を読んでおぉなるほどと思い、ではどうやって論理削除を実装するのかなと思って続きを読むと「『ほんとに削除したデータが必要ですか?』とユーザに確認して、物理削除に変えさせてもらう」と書いてあってズコーとなったことがあるが、要件削っていいなら実装上のどんな問題も消えるわけで、何かもう別世界の議論で自分の仕事には関係ないと思っていた。 が、これだけ繰り返し批判されているからには、論理削除を正しく使う方法なり条件なりを明らかに
nullについて最後まで考える(1) --- T字形で消せるnull，消せないnull - 極北データモデリング
正美氏とかDateの本を読むと、Codd論文を理解するとnullの存在が許せなくなるのだなあ、と思う。 私はこのnull徹底排除の感覚が理解できていない。Codd論文読んだことないし。 比較演算や集計演算の対象に null が混入していると、直感に反する結果が出てくることがあるのはわかる。 同僚がnot null制約を付けていないのを見つけると「付けないとだめっすよ」と言ったりもする。 でも、これはわかった振りをしているだけなのだ。 nullがよくないのは当たり前として、あらゆるアプリケーションでnullを発生させないことができるのだろうか？ どうしても発生するケースがあるのだとすれば、どのnullはあってもよくて、どのnullはあってはならないのか？ where句に出現するnullと、サブクエリが返すnullと、アプリケーションに返されるnullと、罪の重さは全部同じなのか（違うんじゃな
「ドメイン駆動設計」感想(1) - なぜファットモデルになるのか - 極北データモデリング
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 正月にこれを第2部まで読んだ感想を書こうと思って、何ともう2月後半になってしまった。 いろいろ考えさせられたことを忘れてしまう前に感想文を書きます。 (DBばっかりいじっててコードを書かない)俺みたいなのから見たオブジェクト指向設計の特徴に、「実体(エンティティ)の存在は認めても、関係(リレーションシップ)の存在をなかなか認めない」、つまり関係を極力クラスとして立てない、というのがある。 例えば、部門と社員の関係を「所属クラス」として独立させるより、オブジェクト間の関連
生きているうちに自然キーvsサロゲートキー問題に決着を付けたい(1) - 極北データモデリング
営業のアプローチ方法にA,Bがあるとして(例えば「礼状は手書きで出す」「礼状は印刷して出す」とか)、Aの成約率が10%でBのそれが5%なら、「Aしかやらない」というのは悪くない選択だろう。だが我々の仕事は営業とは違っている。 ある量産品の製造方法にA,Bがあるとして、Aの良品率が98%でBのそれが95%なら、Aで製造するのが正しいだろう。だが我々の仕事は量産品の製造とは違っている。 システム開発における失敗プロジェクトは、営業における失注や工場における不良品のようなものではない。つまり、事業を行う上での必要経費ではない。 だから、A,Bどちらの開発技法を採用すべきかを、プロジェクトの成功率で決めることはできない。 仮に自然キーを採用したプロジェクトの成功率が5割で、サロゲートキーを使った場合のそれが9割だったとして、「すべてのシステムにサロゲートキーを使う」という判断は間違っている。1割の
SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る本書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー 「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。 自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。 自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。 自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転
「C.J.Dateの データベース実践講義」からいつか役に立ちそうな話をメモ(2) - 極北データモデリング
一応読了。 へぇと思ったところと、その他思いついたことをメモする。 ORDER BYはリレーショナル演算子ではない 理由は、タプルに並び順のあるもの＝リレーションではないものを返すから。 とはいえ、DateはORDER BYを否定しているわけではない。 便利な道具をリレーショナルモデルの上に積み増すことは、まったく問題ないと考えている。 しかし、積み増した道具が土台のリレーショナルモデルを破壊するなら、その導入には絶対反対の立場を取る。 例えば、ORDER BYはあっても構わないが、ビューの定義にORDER BYを含めることには反対する*1。 outer join否定論も同様。outer joinは便利だが、SQLの世界にnullを呼び込んでしまうのでDateは否定している。 第6正規形とnull 第6正規形の定義は以下の通り。 関係変数Rは、自明でない結合従属性を1つも満たさない場合に限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
