• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:地名のテーブル構造について)

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

このQ&Aのポイント
  • 地名のテーブル構造について、MySQL Version 5.1.41を使用します。テーブル「area」に地名データを格納し、上位概念のデータが必要な場合には新たなテーブルを作成し、外部キーを追加する方法が考えられます。上位概念のデータがさらに変更や追加される場合には、適宜テーブルを追加して関連付けることで柔軟に対応できます。
  • 例えば、テーブル「grouparea」を追加することで、地名データをより包括的なカテゴリで管理できます。さらに、上位概念のエリアや都道府県を追加する場合には、それぞれのテーブルを作成し、関連付けていくことで階層的な地名データの管理が可能です。
  • ただし、このようなテーブルの変更や追加は、データベースの設計やアプリケーションの仕様に合わせて検討する必要があります。適切な関係性やインデックスの設定、クエリの最適化なども考慮しましょう。

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

  • ベストアンサー
  • root139
  • ベストアンサー率60% (488/809)
回答No.2

いっそ、ファイルシステムのディレクトリの様なツリー構造と考えてしまって上位の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
takagoo100
質問者

お礼

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

その他の回答 (1)

  • maiko0318
  • ベストアンサー率21% (1483/6969)
回答No.1

たとえば、隣の家に電話する場合、市内局番-番号ですが、 離れた県になると市外局番-市内局番-番号に、 外国になるとさらに番号が必要ですよね。 それと似ているかな。 携帯番号が10桁で足りなくなって11桁に一斉に変更になりました。 それもどんどん足りなくなってきています。 その都度大改定が必要になります。

takagoo100
質問者

お礼

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