[AccessD] On DB Bloat, Bad DB Design, and various

Stuart McLachlan stuart at lexacorp.com.pg
Tue May 25 21:51:24 CDT 2004


I'm just starting a new project and I'm in two minds about one aspect 
of the database design.  Since this has been discussed so much in the 
last few days, I thought I'd throw it in for discussion.

It's an Accomodation Register type thing for an organisation that has 
lots of staff housing.

AccomodationUnits are children of Properties (Sometimes there will be 
a house on a property, sometimes a block of several units, possibly  
dormitory style with individual rooms etc)

The client wants to store difital photos.  Photos could be of a 
particular unit or of the whole property. I will be storing the name 
of the photo file and pulling the image as required from it's storage 
location.

As I see it there are several possibilities including:

tblPhotos:
AccomUnit/PropertyID
AccomUnit/PropertyType
Filename.......etc

or 

tblPhotos:
AccomUnitID  
PropertyID   
Filename.......etc
(only store ID for the appropriate Property Type)

or

tblAccomUnitPhotos:
AccomUnit  
Filename.......etc

AND
tblPropertyPhotos:
PropertyID  
Filename.......etc



Any comments/suggestions as to how far I should normalize <g> and 
pros/cons of the various approaches - taking into account 
establishing relationships between tables in the BE, maintaining 
referential integrity, ease of data retrieval/maintenance in the FE?



 
-- 
Lexacorp Ltd
http://www.lexacorp.com.pg
Information Technology Consultancy, Software Development,System 
Support.






More information about the AccessD mailing list