Accessの住所を分割するメリットとデメリットを教えてください。

質問

前任者が作成したAccessをメンテナンスしています。
住所のカテゴリーが３段階で作られています。
住所１．都道府県
住所２．市町村から番地まで
住所３．建物名

「これのフォームの住所２と住所３を一緒にして欲しい。
できれば住所１も一緒にして、ひとつのボックスにして欲しい」と、使用者から言われました。
ひとつのボックスにしたほうがフォーム上スッキリとして見やすいから・・・というのが要望の理由のようです。

全てを一緒にすると抽出の段階でやりにくくなるのではと思って調べているところです。
例えば、都道府県別の抽出等。

住所を分割することによってのメリットとデメリットはどのようなことになるでしょうか？

初歩的な質問だと思われるので、このようなことまで質問してすみません。
どなたかご回答いただける方がいらっしゃいましたら教えてください。
よろしくお願いいたします。

回答No.3

DexMachina · ベストアンサー

<分割のメリット>
　○検索が早くなる
　　・都道府県での先頭一致/完全一致の検索、及び市町村での先頭一致検索に対して、
　　 各フィールドに設定したIndexを使用できるため、曖昧検索よりも早い
　　・1フィールドの総文字数が減るため、曖昧検索自体も早くなる(はず)

<分割のデメリット>
　○入力時の打鍵数の増加(→コントロールの移動分：コンボボックスの自動拡張などで、
　　 ある程度の軽減は可能)
　○フォームのヘッダなどに検索条件の入力欄を設ける場合、通常はフィールドごとに
　　 用意することになるので、プログラムを組む上ではやや煩雑

・・・といったところではないでしょうか。
(1フィールドに保存した場合のメリット・デメリットは、上記の内容が逆転)

素人考えですが、使用者が検索速度よりも、1コントロールで入力/参照が可能になることを
重視するのであれば、そうしてしまっても致命的なデメリットはないように思えます。
(なお、ファイルサイズに関しては、Indexが増える分と、各フィールド(特に住所2・3)で文字数
　の余裕を双方で見る必要が生じる分、分割した方が大きくなると思いますが、これも大きな
　問題にはならないかと)

お礼

いつもわかりやすい回答をいただいて本当に助かります。
都道府県とそれ以外の住所の２分割にさせることにしました。
ありがとうございました。

回答No.6

CHRONOS_0

メリットデメリットはご自分で書いておられるじゃないですか

ひとつにしてあれば例えば都道府県で集計したいときに一手間必要
分割してあればまとめて表示するときに一手間必要
というだけのことです

都道府県別に集計したりしないのならユーザーの言うとおりでいいんじゃないですか

お礼

都道府県別に集計することはよくあるので、都道府県とそれ以外の住所の二分割にさせることにしました。
ありがとうございました。

回答No.5

noname#140971

Form_Address:

***************************************************************

Zip_____________[101-1111]
Address1_____[東京都_____]
Address2_____[文京区_____]
Address3_____[太田町１１２番地______________]

***************************************************************

回答No.4

noname#140971

Form_Customer:

***************************************************************

ID:_____________[____1]
KName________[鈴木 一郎________]
Zip_____________[101-1111]
Address_______[東京都文京区太田町１１２番地______________]
Address1_____[東京都_____]　<--------------非表示
Address2_____[文京区_____]　<--------------非表示
Address3_____[太田町１１２番地______________]　<-非表示

[住所更新]

***************************************************************

Address.コントロールソース=[Address1] & [Address2] & [Address3]

Private Sub コマンド_住所更新_Click()
On Error Resume Next
　　DoCmd.OpenForm "Address", , "[ID]=" & Me![ID]
End Sub

Form_Address:

***************************************************************

Zip_____________[101-1111]
Address_______[東京都文京区太田町１１２番地______________]
Address1_____[東京都_____]
Address2_____[文京区_____]
Address3_____[太田町１１２番地______________]

***************************************************************

見かけ上だけですとは、上述のようにすればOKです。
が、[住所更新]コマンドボタンと更新用フォームを用意して更新作業をサポートする必要があるでしょう。

一旦、住所を統合してから分割するのは至難。
また、ユーザも代替わりすれば意見も異なるでしょう。
一々、それらに追随して基本設計を変更していたらテーブルはグチャグチャに。
テーブル設計の基本は譲らずに妥協点を探るのが宜しいと思います。

回答No.2

Dxak

う～ん？
私も分割するほうが良いと思います
表示上の問題であれば、結合は簡単に出来ますから、問題ありませんが・・・分割するとすれば、膨大な処理の上に別途ＤＢを必要とします

しかし、質問の様に、
> 住所１．都道府県
> 住所２．市町村から番地まで
> 住所３．建物名
だけの分割では、例えば、郵便番号を割り当て等、活用する範囲が狭いため、都道府県別に抽出くらいでしか用途的に使い様が無いと言う、問題があるような気がします

都道府県ぐらいなら、モジュールで分割しても問題ないような気がします
その先の、区市郡、町村、番地の分割の処理を考えると、モジュールの労力が酷いことになります

あと、入力上の問題も多々あります
１つにすると、都道府県から入力したものと、区市郡から入力したもの
（政令指定都市だと、都道府県を書かないこともあるため・・・）

但し、使用用途上問題なければ、いいんじゃないで終わるんですがね

表示を１テキストボックス、入力時にポップアップで複数のコンボボックス等で、うまく調整して見たほうが良いと思いますけどね
私の場合、国土地理院の住所コードで保管、入力はコンボボックスで絞込み、印刷・表示などは、１テキストボックスと言う感じです

お礼

ニ分割で食い止めることにしました。
ありがとうございました。

回答No.1

noname#140971

＞「できれば住所１も一緒にして、ひとつのボックスにして欲しい」とは？

見かけ上、それともテーブル設計として？

見かけ上なら、住所１、２、３を非表示にして「ハイ！できました！」もありかなと思います。

補足

見かけ上です。
使用者はフォーム画面での要望を出しています。
パッと見て一目でわかる画面を望んでいるのです。
住所が何故、３フィールドに分かれるのか理解できないのです。
テーブル設計などは頭の中にありません。

＞住所１、２、３を非表示にして「ハイ！できました！」もありかなと思います。

この方法をとると住所全てが表示されなくなってしまうと思うのですが、そういうことではないのでしょうか？