dポイントプレゼントキャンペーン実施中!

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

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

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

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

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

A 回答 (6件)

<分割のメリット>


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

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


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

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

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

お礼日時:2008/03/17 10:03

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



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

都道府県別に集計したりしないのならユーザーの言うとおりでいいんじゃないですか
    • good
    • 0
この回答へのお礼

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

お礼日時:2008/03/17 10:06

Form_Address:



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

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

***************************************************************
    • good
    • 0

Form_Customer:



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

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

[住所更新]

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

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_______[東京都文京区太田町112番地______________]
Address1_____[東京都_____]
Address2_____[文京区_____]
Address3_____[太田町112番地______________]

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

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

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

う~ん?


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

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

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

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

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

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

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

お礼日時:2008/03/17 10:05

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



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

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

この回答への補足

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

>住所1、2、3を非表示にして「ハイ!できました!」もありかなと思います。

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

補足日時:2008/02/21 14:51
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!