教科書的ではなく、現場にあったデータベース設計のコツ

前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。 今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。 図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。 01 ハードウェ

[Mikatsuki]

階層的にやってみる。

[tuki0918]

階層構造（パス方式）が便利そう

[eggist77]

リレーショナルデータベースの階層構造のテーブル設計について参考になりそう。

[labocho]

db 設計

[shiumachi]

パス方式ってデータとしては冗長に見えるけど、検索性能はこの方がいいのか。考えてみれば当然か。しかし中間階層ごとに何らかの処理をかける場合はやはり再帰構造の方がいい気がするんだが、どうだろう。

[sylvan_l]

カテゴリの階層構造のDB設計

[phista]

俺もみとこっと

[wozozo]

DB データベース設計

[toton]

階層構造の設計 「祖先をすべてパス情報として持つパス方式」

[conure]

階層構造を持った商品カテゴリ（親番号方式）のデータ

[yuhei_kagaya]

階層構造の設計について

[tgk]

パス方式 = 不定数の深さを持つ階層カテゴリを一撃でselectする構造

[kdmsnr]

「祖先をすべてパス情報として持つパス方式」