Re: one big tables vs. many smaller

You don't seem to understand Daniel's reply
>> I sometimes denormalize for performance ... but only in response to an
>actual
>> performance issue ... one that comes to my attention from a specific
>end-user
>> complaint and where that complaint can not be dealt with my some other
>means.
>> But even then, only if I can absolutely guarantee that data integrity and
>> security will not be compromised.
>>

He's just stating the opposite of your conclusions

Regards

Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address

On Tue, 9 Apr 2002 14:04:03 +0200, "Steffen Ramlow" <nospam_at_gmx.net> wrote:

>ok, then it seems that the denormalized scheme will be ok, because data
>integrity is ensured
>
>"Daniel A. Morgan" <damorgan_at_exesolutions.com> wrote in message
>news:3CB05CE8.BD0B7CA9_at_exesolutions.com...
>> There are things that are far more important than performance in a
>database: One
>> of them is data integrity.
>>
>> One huge flat file may well outperform two or three tables with an
>inner/outer
>> join. But you can not guarantee data integrity?
>>
>> I sometimes denormalize for performance ... but only in response to an
>actual
>> performance issue ... one that comes to my attention from a specific
>end-user
>> complaint and where that complaint can not be dealt with my some other
>means.
>> But even then, only if I can absolutely guarantee that data integrity and
>> security will not be compromised.
>>
>> Daniel Morgan
>>
>>
>>
>> Steffen Ramlow wrote:
>>
>> > huch - did i ever talked about normalization?
>> >
>> > i talked about (read) performance and possible problems when using the
>> > DE-normalized design
>> >
>> > as i already said - i personally would _always_ use the normalized form,
>but
>> > i need hard facts against the denormalized form, that's why i posted the
>> > question
>> >
>> > this is what i think:
>> >
>> > denormalized:
>> >
>> > pros:
>> > better read performance coz no join is needed (is the join really to
>> > expensive?)
>> > cons:
>> > the table becomes really big
>> > -> maybe a performance hit
>> > -> maintenance difficulties
>> > many null values (what are the problems with them?)
>> > other?
>> >
>> > what i wanted to know is, what others think about this - i don't wanted
>to
>> > hear such general statements like "this is not normalized", this was
>clean
>> > right from the beginning
>> >
>> > "Daniel Morgan" <damorgan_at_exesolutions.com> wrote in message
>> > news:3CAE11DE.381CBABD_at_exesolutions.com...
>> > > You just defeated your own argument in your statement. If there are
>many
>> > many
>> > > null values you do not have a normalized schema.
>> > >
>> > > I don't say this to be insulting ... but it seems that you have not
>> > studied data
>> > > normalization. A normalized table should not be a sparse matrix. And
>your
>> > > arument with respect to the number of "sub" tables is equally not
>relevant
>> > in a
>> > > properly normalized schema. It strikes me that things you are
>considering
>> > should
>> > > never exist.
>> > >
>> > > Daniel Morgan
>> > >
>> > >
>> > >
>> > > Steffen Ramlow wrote:
>> > >
>> > > > "damorgan" <damorgan_at_exesolutions.com> wrote in message
>> > > > news:3CAC87E3.387D6428_at_exesolutions.com...
>> > > > > Much like other things in life ... size has nothing to do with it
>...
>> > it
>> > > > is
>> > > > > what you do with it that counts. The definition of a table should
>be
>> > based
>> > > > on
>> > > > > data normalization tempered by performance. If it belongs in one
>table
>> > ...
>> > > > > stick it there. If not ... don't.
>> > > >
>> > > > if there would only be one or to tables "Sub" then i would out int
>into
>> > the
>> > > > big table
>> > > > but there are up to 10 "Sub" tables - thus a big tables with many
>many
>> > null
>> > > > values
>> > >
>>
>
Received on Tue Apr 09 2002 - 11:07:00 CDT