On Wed, Nov 28, 2012 at 4:41 AM, Niels Kristian Schjødt
wrote:
>
> So my main concern is actually about the cars table, since this one currently
> has a lot of columns (151 - I expect thats quite a lot?), and a lot of data
> (4 mil. rows, and growing). Now you might start by thinking, this could
Let me be devil advocate here :)
First of all, even if you read any basics about normalization, don't take
it to your heart :) Think.
Know that each normalization/denormalization step has it's cons and pros.
E.g. in NoSQL world they often don't normalize much.
What's interesting with PosgreSQL is t
Niels Kristian Schjødt wrote:
> So my main concern is actually about the cars table, since this
> one currently has a lot of columns (151 - I expect thats quite a
> lot?),
That's pretty wide, but not outrageous.
> and a lot of data (4 mil. rows, and growing).
That's not a big deal. It's not unu
Hi Kristian,
> " I can't see why it would make sense to put that into a separate table and
> join in the values "
> You don't normalize for performance. People DEnormalize for performance.
Yes. In short, you seem more of a developer than a RDBMS guy. This is
not a personal fault, but it's a *very
the latest postgres version, you can use covering indexes: tables
aren't accessed at all, bypassing most of your questions. Check with peers if
you've got the indexes right.
Regards,
Willem
> From: nielskrist...@autouncle.com
> Subject: [PERFORM] Database design - best practi
es, this will haunt you.
> - if you have the latest postgres version, you can use covering indexes:
> tables aren't accessed at all, bypassing most of your questions. Check with
> peers if you've got the indexes right.
>
> Regards,
> Willem
>
>
>
> > From:
the latest postgres version, you can use covering indexes: tables
aren't accessed at all, bypassing most of your questions. Check with peers if
you've got the indexes right.
Regards,
Willem
> From: nielskrist...@autouncle.com
> Subject: [PERFORM] Database design - best prac
Hi,
I'm on the hunt for some solid knowledge on a theoretical level about the
performance of postgresql. My question is regarding best practices, and how
architectural decisions might influence the performance. First a little
background:
The setup:
I have a database which holds informations on
