NYCPHP Meetup

[Allen Shaw]

CED wrote:

> http://www.databaseanswers.com/modelling_tools.htm

That's a great list of tools. Something else very interesting to me is 
this note at the end of the page:

> *A short note about about Data Modelling and Database Design ...*
>
>Data modelling and database design are two very different activities.
> 
>For data modelling, the question you are asking is :
>1) What does the world being modelled look like ?  
>   In particular, you are looking for similarities between things. 
>   Then you identify a 'super-type' of thing which may have sub-types. 
>    For example, Corporate Customers and Personal Customers
>
>   If, for example, supplier contacts are conceptually different things from customer contacts, 
>  then the answer is that they should be modelled separately.  
>  On the other hand, if they are merely sub-sets of the same thing, then treat them as the same thing.
>
>2) For database design, you are answering a different question:-
>   how can I efficiently design a database that will support the functions of proposed application or Web Site. 
>   The key task here is to identify similarities between entities so that you can integrate them into the
>   same table, usually with a 'Type' indicator.
>   For example, a Customer table, which combines all attributes of both Corporate and Personal Customers.
>   As a result, it is possible to spend a great deal of time breaking things out when creating a Data Model, and 
>   then collapsing them back together when designing the corresponding database.
>
What interest me here is the writer's understanding that when I'm 
programming an actual application it's in my best interest to 
de-normalize the data model, aiming for fewer tables than my data model 
would have indicated.  I'm assuming this person has good reason for what 
he's saying, but it's something I've never thought of or heard before?

Can anyone suggest reasons why it's better to have fewer tables, or to 
try and combine different types of objects into the same table?  Surely 
it's something to do with better performance (fewer joins, simpler 
queries), right?  Is this a common principle of design that I haven't 
learned yet?

- Allen

-- 
Allen Shaw
Polymer (http://polymerdb.org)