リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
