NYCPHP Meetup

NYPHP.org

[nycphp-talk] data modelling vs. db design (was: ER Diagram tool for MySQL/OS X)

inforequest 1j0lkq002 at sneakemail.com
Tue Oct 4 18:12:56 EDT 2005


Daniel Krook krook-at-us.ibm.com |nyphp dev/internal group use| wrote:

>DB2 uses a technology called Materialized Query Tables (MQTs) that are 
>intended for this type of work.  They were introduced in version 8 but 
>were known in a limited form as summary tables (ASTs) in version 7.
>
>As described above, there are two ways to keep these "perma-views" in 
>synch with the base tables, either user refreshed or system refreshed:
>http://www.ibm.com/developerworks/db2/library/techarticle/dm-0509melnyk/
>  
>

I stayed out of this but am glad Dan added his comments. The developer 
needs to develop code for the app, and in this case the app is no longer 
trying to query the database as was designed -- it's querying summary 
tables as it is now required to do.

Who made that decision? based on data models? Database design? App 
design? All of the above.

Once the *already designed* app (with *already designed* database) was 
analyzed, the system imposed requirements BASED ON THOSE DESIGNS. There 
is more than one way to achieve normalization, but it was irrelevant if 
the database had to be redesigned for performance for this application. 
This recursive design process is at the heart of successful development 
IMHO.

I guess I am just underlining that the initial question of modeling data 
vs. modeling system or application requirements does not always 
encompass database design. In my experience, one must always consider 
the platform and the application from the start, and almost always 
re-design the database around platform factors known later. Yeah, lots 
of "extra work".

One plus for agile software development http://agilemanifesto.org/ and 
an underline of the value of "ben there, done that".

-=john andrews
http://www.seo-fun.com




More information about the talk mailing list