エンティティ内の属性のライフサイクルを揃える - 極北データモデリング
真野正 実践的データモデリング入門 (DB magazine selection) によると、CRUD分析とは別にIRUN分析というものがあるそうだ。 CRUD分析では、各アクティビティがCRUDするエンティティの中の、どの属性が読み書きされるのかまではわからない。 そこでエンティティの属性レベルまで降りて、各アクティビティがどの属性を Import/Refer/Update/Nullify するのかを明らかにするのが、IRUN分析。 分析の結果、同じエンティティの中で生成／消滅するタイミングが違う属性のグループを見つけたら、エンティティを分割する。 例えば、注文エンティティの中の｛ 配送先氏名, 住所, 郵便番号, 電話番号 ｝が注文発生時点では未確定で、後続の「配送・支払指定」アクティビティで値が入力されるとしたら、注文エンティティと配送先エンティティに分割する。 こうすると、それぞれ
事実と真実はどう違うか。また裁判官のキャリブレーションについて - 極北データモデリング
俺が通ってるジムのステアマスターにはテレビが付いていて、いつもテレビ見ながらをステアマスター漕いでるんだけど、この前北斗の拳の再放送見ようと思ってテレビ点けたら放送大学の講義をやっていて、これがえらく面白かった。 それは科学哲学の講義で、テーマは「事実と真実はどう違うか」というものだった。 話の要点は以下の3つだ。 1. 真実は観測できない 先生はこんなフリップを出して話を始めた。 「何かを観測して得たデータを事実と呼ぶならば、事実には必ず誤差が含まれています。事実の集積から、何らかの手続きで誤差を消去して抽出したものを真実といいます」 ガタガタのヒストグラムという事実を集めて、そこから滑らかな曲線を描く真実を取り出すわけだ。 先生の定義によれば、真実は事実のように直接観測できるものではない。 現実世界で見ることも、手で触れることもできないのだ。この点、事実よりも思い込みや妄想に近い存在だ
忘れてしまったほうがいいSQLチューニングテクニックについて - 極北データモデリング
10年ぐらい前はJavaで文字列を連結するときは String ではなく StringBuffer を使ったほうが速いなんて言われてたんだけど、それがテクニックとして有効だったのは「StringBufferを使えばこれこれの内部動作になる」という関係が固定されていたからで、仮にJVMのリビジョンによってどっちが速いかがコロコロ変わったり、文字列の長さが一定以上になると突然あっちの方が速くなったり、みたいな状態だったら「文字列の連結はStringBufferの方が...」はテクニックとして成り立たなくなってしまう。 が、SQLについての言説の一部はまさにこの状態で、本来成り立たないことがチューニングテクニックとして語られていると思う。 そういうのを暗記するのはやめて実行計画を見ましょう、という話。 「INとEXISTSはどっちが速いか」の不毛 昔から「INを等価なEXISTSに書き換えると速
「NULLがUNIQUE制約に縛られないことを利用する」のは、正当なNULLの使い方 - 極北データモデリング
リンク先は「UNIQUE INDEXを振った列に複数のNULLを投入できること利用して、ユニークであるべきユーザIDの使い回し(=退会したユーザのIDを新規ユーザに開放する)を実現する」という話。 アクティブなユーザ名はユニークにしたいけど削除されたユーザの情報は残したい。でも削除済みユーザテーブルは作りたくない とかいうワガママを発揮したい時にdeleteフラグに使えないかなーなんてだめですかそうですか。なんか他にまともな方法無いですか…。 MySQLのこういうのっていかがなもんか - 桝原翔市的博客 いやーこれはまともな方法じゃないでしょうか。 「NULLはNULLに一致しない」のが絶対の原則なのだから、NULLを使ってUNIQUE制約を回避するのは裏技でもwork-aroundでもない、正当なテクニックでしょう。 私はTM派なので実表上にnullを発生させる設計はしないが、Nulla
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
