こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

地名のテーブル構造について

MySQL Version 5.1.41

このジャンルでお願いします。
例えば地名を格納する

テーブル「area」
+------+-------+
| id | name |
+------+-------+
| 1 | 渋谷1丁目|
+------+-------+
| 2 | 渋谷2丁目|
+------+-------+

があったとします。
次にその上位?(これらの丁目を包括する)データが必要なった場合に
新たにテーブルを作ってその外部キーをテーブル「area」に新たに追加する方法が良いのでしょうか?

テーブル「grouparea」
+------+-------+
| id | name |
+------+-------+
| 1 | 渋谷区|
+------+-------+

テーブル「area」←このテーブルの列構造をその都度変える
+----+---------------+-----------+
| id  | grouparea_id  |   name  |
+-----+-------------+-----------+
| 1  |      1    | 渋谷1丁目|
+-----+-------------+-----------+
| 2  |      1    | 渋谷2丁目|
+-----+-------------+-----------+

でもこれだとさらにその上位概念のエリア「東京」や「東京」は
「関東」、あるいは「東日本」といった具合に追加したくなった場合に、
順番的に「grouparea」テーブルの先に「ken」テーブルを追加してて
後に「grouparea」テーブルを追加したくなったら

テーブル「ken」
+------+-------+
| id | name |
+------+-------+
| 1 | 東京都|
+------+-------+

テーブル「area」
+----+---------------+-----------+
| id  |     ken_id  |   name  |
+-----+-------------+-----------+
| 1  |      1    | 渋谷1丁目|
+-----+-------------+-----------+
| 2  |      1    | 渋谷2丁目|
+-----+-------------+-----------+

次に「grouparea」テーブルを追加したくなったら

テーブル「ken」
+------+-------+
| id | name |
+------+-------+
| 1 | 東京都|
+------+-------+

テーブル「grouparea」
+----+---------------+-----------+
| id  |     ken_id  |   name  |
+-----+-------------+-----------+
| 1  |      1    | 渋谷1丁目|
+-----+-------------+-----------+

テーブル「area」
+----+---------------+-----------+
| id  | grouparea_id  |   name  |
+-----+-------------+-----------+
| 1  |      1    | 渋谷1丁目|
+-----+-------------+-----------+
| 2  |      1    | 渋谷2丁目|
+-----+-------------+-----------+

このような変更しなくてはいけないですよね?(このような変更が可能なのかは分かりませんが・・・)
自分的にはこのやり方は違うような気がするのですが、
なにか良いやり方や考え方があればアドバイス頂けないでしょうか?

投稿日時 - 2013-12-07 09:43:57

QNo.8376451

すぐに回答ほしいです

質問者が選んだベストアンサー

いっそ、ファイルシステムのディレクトリの様なツリー構造と考えてしまって上位のIDを保持するようにしてはどうですか?

例) テーブル「area」
+----+----------+---------+
| id | name    | upper_id |
+----+----------+---------+
| 1 | 関東    | (null)  |
+----+----------+---------+
| 2 | 東京都   | 1     |
+----+----------+---------+
| 3 | 渋谷1丁目 | 2     |
+----+----------+---------+
| 4 | 渋谷2丁目 | 2     |
+----+----------+---------+


構造的には、県の上位に市を設定したり、自分自身のIDを上位IDに設定する事も出来てしまいますから、そこら辺はアプリケーション側で管理する必要が有りますが。

さらに地域の種別を表すコードのカラムを設けて、どの階層かを管理しても良いかも知れません。

参考URL:http://www.geocities.jp/mickindex/database/db_tree_ns.html

投稿日時 - 2013-12-07 12:13:48

お礼

ご回答ありがとうございます。
なるほど、上位IDの階層構造ですね。
それにroot139さんが仰るように種別のIDを持たせるのが
今のところ現実的な感じですね。
参考になりました。

投稿日時 - 2013-12-07 17:48:19

ANo.2

このQ&Aは役に立ちましたか?

4人が「このQ&Aが役に立った」と投票しています

回答(2)

ANo.1

たとえば、隣の家に電話する場合、市内局番-番号ですが、
離れた県になると市外局番-市内局番-番号に、
外国になるとさらに番号が必要ですよね。

それと似ているかな。

携帯番号が10桁で足りなくなって11桁に一斉に変更になりました。
それもどんどん足りなくなってきています。

その都度大改定が必要になります。

投稿日時 - 2013-12-07 11:11:40

お礼

ご回答ありがとうございます。
たしかにちょっとした変更じゃ対応できなそうな気がします。

投稿日時 - 2013-12-07 17:45:02

あなたにオススメの質問