Database Design, One field table

[Calgary_Neil]

Hi. I have been fighting with myself over this design question, Is a one field table valid and of good design?

I'm trying to create a database which records locations though time. So for a "place" it it will have
a name (one or more)
a population (zero or more census)
a location (GeoCoded maybe, an address maybe)
be located in many different regions (recursive to Places?)
may have a control location which could change (Capital)

So in my mind I see the Places table as a single field table using a autonumber, with relationships to these tables which would have a To/From date fields.

Now I'm also thinking that there is no difference between District, City, Zone, County, Region, State, and Country so that would be all recursive. (note some GeCodes would be to give a general area)

So does this sound right???

Calgary_Neil

 

[Calgary_Neil]

Good Point about London Places anyway... This will sound strange but I haven’t written much in accesss, and code is 20 years ago. (I will learn will soon).

Are you saying drop the PlaceFk from the other tables or just drop the centre table. If so what does that look like in a ERD ?

 

[xenou]

I'm just thinking that the center table (autonumber or number single field table) isn't actually going to *do* anything useful. But it's hard to say. I really would need to see some sample data. Everything discussed so far is pretty general. My only point is that once you have creating a single field autonumber or number table, I'm not sure you'd ever need to actually use it. So maybe it's unnecessary. As far as an ERD goes, I can't really create an ERD for you without knowing your data.

 

[Calgary_Neil]

Got busy here, Will be back shortly (Tonight)