タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

DBMSとModelingに関するscrewboundのブックマーク (2)

  • DBエンジニアのミックさんが語る、RDBで階層構造データを扱う「入れ子集合モデル」の将来性

    これまで階層構造データはリレーショナルデータベースでうまく扱えませんでしたが、その解決策としてジョー・セルコが提案したのが「入れ子集合モデル」です。この手法を紹介した『プログラマのためのSQLグラフ原論』の刊行にあたり、翻訳されたDBエンジニアのミックさんに入れ子集合モデルの将来性についてうかがいました。 なぜRDBで木と階層構造を扱う手法が1冊の書籍に? ――『プログラマのためのSQLグラフ原論 リレーショナルデータベースで木と階層構造を扱うために』についてミックさんにうかがいます。最初に、書がどういうなのか教えていただけますか? ミック:内容としては、リレーショナルデータベース(RDB)でグラフ構造の一つである木と階層構造を扱うための方法論「入れ子集合モデル」をメインに解説しています。RDBには大きな問題があり、入れ子集合モデルがそれを解決しうる手法だと見込まれています。その問題と

    DBエンジニアのミックさんが語る、RDBで階層構造データを扱う「入れ子集合モデル」の将来性
  • 論理削除はなぜ「筋が悪い」か

    「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」(トランザクション)は不定形(どのテーブルをどのように修正するかはアプリケーション依存)だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる(というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが

  • 1