2

I have a system with the concept of addresses (as in postal addresses). We have an Address table with fields Address1-4, City, PostCode.

I am trying to figure out the best way to store this Address data so that it can be queried easily in the UI. Users don't generally appreciate that there are separate fields (except for perhaps Post Code) so asking them to put the right string in 5 search fields doesn't work. I feel it needs to be a single search field which will try and match against part of the address.

For example

Address1: Flat 23
Address2: Big Towers
Address3: 1 Baker Street
Address4: (Blank)
City: London
PostCode: W1U 6AA

So for example if wanted to find "Flat 23 in Big Towers" I might like to type "23 Big Towers" or "Big Towers 23" into a query box and expect it to find the above. But because the fields are separate this is difficult to achieve.

The app is completely proprietary so making changes to how the address is stored or storing it in multiple ways is perfectly feasible. The app is C# UI and Java middle-tier.

Does anyone have any suggestions about how to store the Address and structure a search UI + query to make this straightforward from a user's points of view?

EDIT: Added an example

Matt
  • 19,570
  • 12
  • 62
  • 104
Mike Q
  • 21,350
  • 19
  • 80
  • 124

4 Answers4

2

Based off your example you could have a generated field that concatenates all other fields (with space delimiters). Then you could just query this field instead of the others, such that (with your example):

Generated field:

Flat 23 Big Towers 1 Baker Street London W1U 6AA

Query:

SELECT
  * 
FROM
  Address
WHERE
  GeneratedField LIKE '%searchTerm1%' 
AND
  GeneratedField LIKE '%searchTerm2%'
AND
  GeneratedField LIKE '%searchTerm3%' 
Stafford Williams
  • 9,434
  • 7
  • 44
  • 94
1

Do you have the option of hooking up to a 3rd party API? You could send a request over to Google or Yahoo maps with the original string, then get back a nicely delimited set of data that you could use to compare. That may be easiest - let Google's servers do it for you! As a direct answer, I'd say store each address component separately, then query against the API lookup results.

I think there's some interesting additional discussion here:

Parse usable Street Address, City, State, Zip from a string

Community
  • 1
  • 1
eouw0o83hf
  • 8,640
  • 3
  • 51
  • 66
  • I already have the data delimited cleanly, it's more of a problem to figure out how to make searching for this data as easy as possible. – Mike Q Feb 01 '12 at 22:18
  • I was envisioning giving the user a single text input box, letting Google parse it into meaningful address components, then compare those component results against the database and find the closest match - are you looking for something more specific? – eouw0o83hf Feb 01 '12 at 22:21
  • I've added an example, maybe that makes it clearer. While I can change the internals of the app we deploy this inside other companies so I would prefer to avoid going out to something like google as it raises security issues. Plus I only want to search the addresses stored in the system rather than generally. For example an install may only have a few thousand relevant addresses. – Mike Q Feb 01 '12 at 22:26
0

I like storing addresses as an xml snippet myself. with scope for extra attributes like town, country, country etc.

Gives you a lot more options and elbow room.

Tony Hopkinson
  • 19,528
  • 3
  • 29
  • 38
0

You can do it simply by using a parameterized query. Just surround each text value with % for MSSQL, and add them as parameters for this query:

SELECT * FROM Addresses WHERE Address1 LIKE @Address1 OR Address2 LIKE @Address2 OR Address3 LIKE @Address3 OR Address4 LIKE @Address4

parameters.Add("@Address1", String.Format("%{0}%", address1Text.Text)

scottm
  • 26,493
  • 22
  • 102
  • 155
  • I only want to have a single text box for users to enter search queries as it will be non-intuitive for a user to figure out which field contains what, and this probably won't be consistent across all addresses in the system. – Mike Q Feb 01 '12 at 22:46