From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Alex Turner" <armtuk(at)gmail(dot)com> |
Cc: | "Lewis Cunningham" <lewisc(at)rocketmail(dot)com>, "vladimir konrad" <vk(at)dsl(dot)pipex(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [OT] "advanced" database design (long) |
Date: | 2008-02-04 12:09:44 |
Message-ID: | dcc563d10802040409i583c64d3w69118172e3705dce@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Feb 3, 2008 10:14 PM, Alex Turner <armtuk(at)gmail(dot)com> wrote:
> I"m not a database expert, but wouldn't
>
> create table attribute (
> attribute_id int
> attribute text
> )
>
> create table value (
> value_id int
> value text
> )
>
> create table attribute_value (
> entity_id int
> attribute_id int
> value_id int
> )
>
> give you a lot less pages to load than building a table with say 90 columns
> in it that are all null, which would result in better rather than worse
> performance?
But you're giving us a choice between two bad methodologies.
Properly normalized, you'd not have a table with 90 nullable columns,
but a set of related tables where you'd only need to store things in
the subordinate tables for the relative data points.
The worst thing about EAV is that it makes it very hard to figure out
what the heck is going on by just looking at the database schema.
It's easy to develop and hard to maintain. We had a person do
something like that last place I worked and it took weeks for a new
developer to figure it out and replace it with a properly relational
model, because there were little corner cases all through the code
that kept popping up.
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-02-04 12:18:55 | Re: PostgreSQL Certification |
Previous Message | Nicolas KOWALSKI | 2008-02-04 11:40:19 | Re: problem with ORDER BY |