Re: one big tables vs. many smaller

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 Sun Apr 07 2002 - 09:51:20 CDT