ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    イミュータブル(不変)なDB設計

    このエントリーを含むはてなブックマーク はてなブックマーク - イミュータブル(不変)なDB設計 あとで読む
    RDBの設計、モデリング手法について調べていたら、我流の欠点が見えてきた。

    イミュータブルデータモデル(入門編) from Yoshitka Kawashima


    イミュータブルデータモデル(世代編) from Yoshitka Kawashima


    イミュータブル - Wikipedia

    オブジェクト指向プログラミングにおいて、イミュータブル(immutable)なオブジェクトとは、作成後にその状態を変えることのできないオブジェクトのことである。対義語はミュータブル(mutable)なオブジェクトで、作成後も状態を変えることができる。

    イミュータブルなオブジェクトを使うと、複製や比較のための操作を省けるため、コードが単純になり、また性能の改善にもつながる。
    しかしオブジェクトが変更可能なデータを多く持つ場合には、イミュータブル化は不適切となることが多い。
    このため、多くのプログラミング言語ではイミュータブルかミュータブルか選択できるようにしている。



    最近、DBの設計で、論理削除はダメだという話が盛り上がっていた。
    Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
    Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か
    論理削除が云々について - mike-neckのブログ
    RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    上記のスライドを見て、CRUDのUやDの問題点について、少しずつ理解してきた。
    参考文献に挙げられていた「楽々ERDレッスン」も読んでみた。

    楽々ERDレッスン (CodeZine BOOKS)
    (株)スターロジック 羽生 章洋
    翔泳社
    2006-04-18
    ¥ 2,376


    以前、主キーについて悩んだことがあったけど、ミュータブル前提だったから、生じた問題だったと分かった。

    衝突しにくいハッシュ値をMySQLの代理キーにする方法 - 浜村拓夫の世界

    連番の欠点は、何かの事情で、連番カラムのデータが失われたら、再び同じ連番を各レコードに割り当てることがで困難であることです。
    物理的なデータ削除等で、連番に欠番が生じていれば、再度連番を割り当てても、ズレが生じます。
    主キーに、このような不安定要素を残しておくことは、堅牢なシステムとは言えません。



    「id」以外で、主キーのカラム名は何がいいだろ? - 浜村拓夫の世界

    テーブルが破壊されて、データを最初から流し込む必要があるとき、不要になったレコードがあって、レコード数が減ったりしていると、歯欠けになった分だけ、それ以降の連番の割り当てがズレちゃうんだよね。



    テーブルがイミュータブルで、DELETEが一切無ければ、連番が歯欠けになることはなかったんだね!
    主キーは、ただのポインターでOKと。

    なるほどー、と思うこと、しきり。
    もうちょい勉強してみよう!
    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/1200-795b2220

    FC2Ad