[TriLUG] OT: Opinion Poll: Database design

[Bob Shepherd]

Brian,

Although you say the one-to-many mappings are not needed, I think the real 
virtue, other than OOD, of dividing this up into separate tables, is that it 
allows you to scale your application more easily.  By providing one-to-many 
relationships among the tables, you can more easily add capabilities later.  
For instance, if your payment information table is a dependent of your 
customer table, you then have the option to add an infinite number of payment 
options for that customer.  Lord knows specifications can change over time.  
Better to avoid having to restructure the db later.

Bob Shepherd

On Tuesday 20 July 2004 9:57 am, Brian Henning wrote:
> Howdy Folks,
>   Just wondering what people's opinions are on the following topic:
> a) One table with copious fields
> -vs-
> b) Multiple tables with fewer fields each, linked somehow
> ex:
> a) One table with 30 fields containing all possible customer data (name, 2
> addresses, 4 phone numbers, e-mail, payment method, etc)
> -vs-
> b) One table with names and IDs (2 or 3 fields), one table with addresses
> (11 fields), one table with contact info (6 fields), one table with payment
> data (4 or 5 fields).
>
> Note that this is intentionally an example where there is no need for
> many-to-one mapping, with the exception of two addresses (billing and
> shipping) to one customer, so the many-to-one ease facilitated by option
> (b) isn't much of an incentive in this case.
>
> This is entirely academic, as I've already made my decision for the
> database in question..  I'm just curious what others think, especially if
> any opinions happen to address performance vs. storage space -type issues.
>
> Cheers,
> ~Brian
> ----------------
> Brian A. Henning
> Strutmasters.com
> 866.597.2397
> ----------------