NYCPHP Meetup

[Tim Gales]

inforequest wrote:
> 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, 

Have a look at:
'The Dangerous Illusion: Denormalization, Performance and Integrity'

http://dmreview.com/article_sub.cfm?articleId=5251

Read the part that starts off with: "a fully normalized relational 
database consists of R-tables. Each represents just one entity type..."

It strikes me that normalization of data follows a strict path --
first normal, second normal, and so on.

That is, there is not such a thing as  "more than one
'right way' " to normalize data -- not even with Perl packages.

> 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". 

"... conceptual modeling is inherently an informal endeavor, logical 
modeling—which is where normalization applies—is based on formal theory. 
Otherwise put, while business modeling is all art, logical database 
design is, at least in part, science. And the theory is there not for 
its own sake, but to guarantee consistency and avoid the practical 
problems...

-- Fabian Pascal
(the same author of the above article)

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


been there and 're-done' that you mean..

-- 
T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com