Skip site navigation (1) Skip section navigation (2)

Re: Advice needed

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: Advice needed
Date: 2010-10-29 22:23:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
i(dot)geografica(at)alt-shn(dot)org (ALT SHN) writes:
>  2 - Relational Database Theory advices you to do normalization at
> least to 3rd normal form. However, if I strictily follow this, I'll
> end up with tens of tables, and all of them will have to be filled
> from scratch. But if I stick to 2nd normal form, I'll end up with only
> 6 tables wich makes it much easier for users to fill them. So, my
> question is: given the computational capabilities of today, and given
> the expected size of this DB (10000 records), Wouldn'd be better to
> let to normalization as of 2nd normal form?

Well, the point of all the successive normal forms (and I think they're
up to 6, these days!) is that each indicates some sort of anomalous
structuring of data that can take place, and which the particular normal
form helps to prevent.

If you're not worried about particular anomalies, perhaps because your
application that establishes the data won't even allow them to come into
existence, then it may be quite reasonable to ignore extra layers of

Alternatively, if it's not a big deal to need to resolve anomalies by
hand, then it may not be hugely important to protect yourself from them.

I know I frequently feel uncomfortable if I see a schema growing, with
little value falling from that growth.  Leaping from 6 tables to 30
would strike me as a distressing growth of complexity.  I wouldn't
expect "proper normalization" to bloat the schema that much, though.
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))

In response to

pgsql-novice by date

Next:From: LewDate: 2010-10-30 18:39:44
Subject: Re: Advice needed
Previous:From: ALT SHNDate: 2010-10-29 21:27:51
Subject: Advice needed

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group