DBエンジニアのミックさんが語る、RDBで階層構造データを扱う「入れ子集合モデル」の将来性
これまで階層構造データはリレーショナルデータベースでうまく扱えませんでしたが、その解決策としてジョー・セルコが提案したのが「入れ子集合モデル」です。この手法を紹介した『プログラマのためのSQLグラフ原論』の刊行にあたり、翻訳されたDBエンジニアのミックさんに入れ子集合モデルの将来性についてうかがいました。 なぜRDBで木と階層構造を扱う手法が1冊の書籍に？ ――『プログラマのためのSQLグラフ原論 リレーショナルデータベースで木と階層構造を扱うために』についてミックさんにうかがいます。最初に、本書がどういう本なのか教えていただけますか？ ミック：内容としては、リレーショナルデータベース（RDB）でグラフ構造の一つである木と階層構造を扱うための方法論「入れ子集合モデル」をメインに解説しています。RDBには大きな問題があり、入れ子集合モデルがそれを解決しうる手法だと見込まれています。その問題と
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
「理論から学ぶデータベース実践入門 ― リレーショナルモデルによる効率的なSQL」 - tmtms のメモ
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者: 奥野幹也出版社/メーカー: 技術評論社発売日: 2015/03/10メディア: 単行本（ソフトカバー）この商品を含むブログ (9件) を見る ひょんなことから著者の奥野さんから頂きました。読み終えたのは3月頭なのに、2ヶ月も経ってからブログを書くという遅筆ぶりです。 この本はもともと2月末に発売予定だったらしいのですが、3/10に販売延期になりました。 『理論から学ぶデータベース実践入門』 発売延期及びテスト販売購入のお客様への書籍交換対応のお詫びとお知らせ：重要なお知らせ｜技術評論社 テスト販売という限られた部数とはいえ、一旦販売したものを正誤表対応ではなく刷り直して交換対応というのは、電子書籍ならともかく、紙の書籍でやるとはすばらしいです。神対応と言ってもいいの
makopi23のブログ SQLアンチパターン読書会 ：番外編「論理削除の四方山話」に参加しました
2015/4/27(月) SQLアンチパターン読書会 ：番外編「論理削除の四方山話」に参加してきました。 DoorKeeper https://sqlap.doorkeeper.jp/events/23719 以下の書籍をターゲットとした読書会なのです。 場所は前回と同じく、品川シーサイドにある株式会社マーベラスさんです。 参加者は14名かな。 前回の読書会で全25章を終えたので、今回は特別編のような位置づけなのです。 今回のテーマは「論理削除」！ そして今回はなんと @t_wada さんに加え、そのお父さんであり書籍の監訳者でもある和田省二氏も参加してくださいました！ 以前、DevLoveでも和田さん親子によるSQLアンチパターンのイベントがありましたね。 そんときは私も参加してブログにも書きました。 makopi23のブログ： 「SQLアンチパターン・レトロスペクティブ - データベー
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
