About that irrational fear...
Sometimes code is your best friend.
I like your URL approach.
-j-
On Apr 22, 2008, at 9:35 AM, Mr. Frank Cobia wrote:
I had thought of something along theses lines, but I was worried
about searches. Most of the time I will not be accessing the
locations through the tree, but doing a search such as where
location = Georgia which will also need to pull up anything with a
location in a country, metro region or city that is inside Georgia.
It seems like this type of structure does not lend itself well to
searches.
One thing I had thought of doing is having a sort of code where the
code is made up of the code of its parent. For example the City of
atlanta might have a code of "us.georgia.metroatlanta.fulton" This
way if I want to find an object with location of Metro Atlanta I
could do: where location.code = 'us.georgia.metroatlanta'
What I was worried about is there are times when the tree structure
changes (usually because of human error classifying the county or
city) then the code might get out of sync. Is that fear irrational?
Thanks,
Frank
On Apr 22, 2008, at 9:42 AM, Robert Walker wrote:
Optionally, you could use a reflexive relationship for this. I've
used them in the past for this type of situation and it seemed to
work out well. This would allow you to have an arbitrarily deep
tree structure using a single database table and single EO.
I can't think of any particular disadvantages to this type of
relationship, and the structure is very simple. You create a one-to-
many relationship that references a different row in the same
table. The only caveat I'm aware of is to watch out for recursive
associations.
I've built similar database structures for bills of material
(although they are more complex than this, and involve a many-to-
many reflexive relationship). Basically you just have to make sure
that any "root" node is never used anywhere within that particular
branch of the tree. This can usually be accomplished though the UI,
but it's best to recursively validate the branch of the tree on save.
---------------------------------------------------------------------------------
Location
---------------------------------------------------------------------------------
id
name
type (Country, Region, State, Metro Area, County, or City)
parentID
---------------------------------------------------------------------------------
parent (to-one)
children (to-many)
---------------------------------------------------------------------------------
United States (Country)
--> South East (Region)
----> Alabama (State)
----> Arkansas (State)
----> Georgia (State)
------> Atlanta (Metro Area)
--------> Fulton (County)
----------> Atlanta (City)
----> ....
--> North West (Region)
----> Washington (State)
----> Oregon (State)
----> Montana (State)
Watch out for infinite recursion problems as illustrated below:
United States (Country)
--> South East (Region)
----> Alabama (State)
------> United States (Country) <------- Causes infinite recursion
--------> South East (Region)
----------> Alabama (State)
------------> United States (Country) <------ As is obvious here
since you never find leaf nodes
On Apr 22, 2008, at 8:33 AM, Mr. Frank Cobia wrote:
Thanks. I will look into this and see if I can make it work.
Frank
On Apr 21, 2008, at 3:45 PM, Chuck Hill wrote:
On Apr 20, 2008, at 6:15 PM, Mr. Frank Cobia wrote:
I have a database design question. I am posting it to the
WebObjects list because I am building a WebObjects app and want
a solution that works well for EOF.
I have a table of data that has to have a location associated
with it. Unfortunately the level of the location is not
constant. The data can be associated with a Country, Region,
State, Metro Area, County or City. Each of those levels is its
own table with relationships pointing to the related locations.
i.e. a State knows which Region it belongs to and which Metro
Areas belong to it.
I have been unable to come up with a design that seems elegant.
I have thought of having 6 separate relationships to each of the
location levels, but it seems to duplicate data and the data
could get out of sync if a state is moved to a different region
or a City is moved to a different county.
Has anyone had a situation like this and come up with a good
solution?
This seems like a good place for inheritance with an abstract EO
of Location with concrete subclasses of Country, Region, State,
Metro Area, County or City. For some operations, having them in
separate tables might cause more fetches than you want. Using
single table inheritance would address that.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/robert.walker%40bennettig.com
This email sent to [EMAIL PROTECTED]
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/frank.cobia%40f2technology.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/james%40jimijon.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]