[Nottingham] TALK: Relational databases, SQL and PostgreSQL.

[Ovid]

--- Michael Erskine <msemtd at yahoo.co.uk> wrote:

> I don't want to diverge too much from the conversation but I've seen
> some 
> creative non-normalised database design with column redundancy for
> rapid lookups and lock avoidance.

A cardinal rule of software development:  optimize for *correctness*. 
Then, and only then, do you optimize for performance.  So for
databases, you normalize the database and only when you have a
demonstrable performance problem under real-world conditions do you try
to resolve it.  Unfortunately, many people reach for denormalization
right away without finding out what causes the performance problem.  Is
it I/O bound or CPU-bound?  Can it be traced to certain SQL statements
and have 'explain's been run over them?  That often means things like
vertical or horizontal partitioning, creative indexes, etc. 
Denormalization may be an option, but you have to have hard-numbers to
back it up.  Otherwise, you're just guessing and this leads to more
problems down the road.

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/