SQL: ナイーブツリーと閉包テーブルモデル - CUBE SUGAR CONTAINER
今回のエントリは以前かいた SQL のアンチパターン「ナイーブツリー」に関する記事の続き。 blog.amedama.jp 再帰クエリをサポートしていない RDBMS で再帰的な構造のスキーマを作りたいときの解決策のひとつとして閉包テーブルモデルを扱う。 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65 $ mysql --version mysql Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) using EditLine wrapper 下準備 まずは下準備として MySQL にデータベースを作るところまで。 今回使ったのは Mac OS X なので MySQL は Homebrew でインストールする。 $ b
第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か | gihyo.jp
はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート（根）と呼ばれるノードを始点として、（通常）複数のリーフ（葉）と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある「木」の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ（フォルダ）によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
2012年05月: プログラミングが好き！
プログラミング好きが、プログラミングのためのソフトウエア開発周辺の興味ある分野を勉強する記録。プログラミング言語、IT、ICT、情報処理技術、設計技法、数値計算、データベース、システム、SCM、画像処理、開発環境、ツールなどなど。 『アナリシスパターン-再利用可能なオブジェクトパターン』が難解なので、UMLの記法で図を書き換えながら自分なりに理解して行く勉強会の第一回目です。 2章の前半部分。パーティアナリシスパターンは比較的分かりやすいパターン。何度も類似の組織階層などをクラス化あるいはデータベースで扱って来ているので漠然と似たような構成は考えたことがある。例も身近。図の書き換えの練習にもなる。 型図の書き換えにはAstah*Professionalのクラス図を使いました。 「図2.1 アドレス帳の初期モデル」 これはよくある図。ちなみに、元の型図では集約は書かれていないが「(0..1)
ナイーブツリー - Strategic Choice
ナイーブツリー（Naive Trees, 素朴な木） どういうこと？ 【したいコト】 階層（ツリー状）構造をテーブルに格納します。階層構造の代表例には、組織図や掲示板のスレッドなどがあります。 【やらかしたコト】 自分の親を格納する列を用意します。この列は、自分のテーブルに外部キーを設定します。このような設計を「隣接リスト（Adjacency List）」とも呼びます。 どうしてヤル？ 隣接リストは、階層的なデータの格納に用いられる、最も一般的な設計です。 どうしてダメ？ 階層の検索がやりにくい 階層の深さに制限のないSQLが書けません。 アプリケーション側に任せるしかありませんが、パフォーマンスに問題が発生します。 階層のメンテナンスがやりにくい サブツリー全体を削除する場合、すべての子孫を特定するために複数回クエリを実行し、最下層から順番に子孫を削除する必要があります。この順番を守らな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLで木と階層構造のデータを扱う――入れ子集合モデル