[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