From: | Chris Angelico <rosuav(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Need sql to pull data from terribly architected table |
Date: | 2012-10-24 16:56:39 |
Message-ID: | CAPTjJmpAKM-99M6Wxxdm9+bC3GNtiwz6D+uOSiZcOPP5oaLW0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Oct 25, 2012 at 2:42 AM, Steve Litt <slitt(at)troubleshooters(dot)com> wrote:
> Also, with the organization they're using, one can make new "columns"
> on the fly. ... Anyway, the keypuncher is punching
> data, comes across a brand new type of data (let's say "artist"), so
> for this row the keypuncher puts in a key-value pair of "artist=Lady
> Gaga". From a practical point of view, data structure could be change
> at key entry time, and needn't have been anticipated by the programmer
> nor recompiled or reorganized when a new type of data element entered
> the requirements.
That's wonderfully flexible, but it forfeits the protection that a
well-designed schema gives. A system like that is likely to end up
with different records storing the same data under slightly different
names, and you'll have a massive proliferation of "columns" that have
only a single row's value in them. That's fine if that's what you
want, but from a data entry standpoint, I think it's _too_ flexible
for most purposes.
ChrisA
From | Date | Subject | |
---|---|---|---|
Next Message | Hellmuth Vargas | 2012-10-24 17:22:50 | como exportar separado por comas una tabla grande |
Previous Message | Scott Marlowe | 2012-10-24 16:18:53 | Re: Plug-pull testing worked, diskchecker.pl failed |