NYCPHP Meetup

[Kenneth Downs]

>> Normalization can have a huge impact on your apps -- it
>> can reduce many
>> data entry errors and eliminate others entirely.  That is
>> its purpose.
>> Without normalization all of the time you spend supporting
>> a slow app will
>> be spent fixing errors in bad data.
>>
>> But querying data is a different thing.  If you have known
>> common queries
>> that aggregate and join data, then by all means create
>> some summary system
>> that is, hopefully, automatic and guaranteed to be right.
>> This is not
>> really denormalization, though the relational theorist
>> will argue it is.
>> What it is in fact is the creation of derived tables based
>> on normalized
>> tables.
>>
>> But anyway, normalize the tables users can directly modify, and use
>> summaries derived from those normalized tables.  Then you
>> get accurate
>> data coming in and that makes for accurate summaries.
>
>
> Excellent point Kenneth,

Thank you.

>
> This is the very thing Craig S. Mullins envisions in his "Death of
> Denormalization" articles. [1][2]   "With MQTs, you can achieve the best
> of both worlds: fully normalized tables to ensure data integrity during
> modification and MQTs for efficient querying." [2]   In essense, you don't
> have to change your data model just your hardware or software.

His point is subcategory of the entire concept of automation and how it is
put into context with normalization.

>
> But Fabian Pascal says the solution isn't that denormalization will be
> rendered obsolete by faster physical resources, it's rethinking those
> software systems in the first place to support true high-form
> normalization that should eliminate performance issues.   "Hardware,
> product and optimization improvements are, of, course, always desirable
> and welcome, but they are only add-ons, not substitutes for the real and
> fundamental solution: well implemented TRDBMSs, whose performance is not
> hindered, but actually enhanced with fully normalized databases." [3].
>

Generally I ignore Fabian Pascal.  His solution too often is to tell
everybody how wrong they are, and how they don't know enough.  There are
more elegant authors out there who realize you have to talk to people
where they are at.

>
>
> [1] The Death of Denormalization
> http://www.dbta.com/columnists/craig_mullins/dba_corner_0104.html
>
> [2] Materialized Query Tables and the Death of Denormalization
> http://www.zjournal.com/Article.asp?ArticleId=875
>
> [3] Irrational Exuberance
> http://www.dbazine.com/ofinterest/oi-articles/pascal18
>
>
>
>
> Daniel Krook, Advisory IT Specialist
> Application Development, Production Services - Tools, ibm.com
>
> Personal: http://info.krook.org/
> BluePages: http://bluepages.redirect.webahead.ibm.com/
> BlogPages: http://blogpages.redirect.webahead.ibm.com/
>
>
> _______________________________________________
> New York PHP Talk Mailing List
> AMP Technology
> Supporting Apache, MySQL and PHP
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.nyphp.org
>


-- 
Kenneth Downs
Secure Data Software
631-379-0010
ken at secdat.com
PO Box 708
East Setauket, NY 11733