From: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: More then 1600 columns? |
Date: | 2010-11-12 07:17:50 |
Message-ID: | AANLkTin84spk-3d_ZVgdWZAcvdMubHek2UXij-hdiusg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hey Mark,
Yeah, I can't imagine an entity in a real project even with more than 100
columns. Its rare case.
But if you entities (rows/tuples) of some class (table) can contains
variable
set of columns (properties) you can look at hstore contrib module.
2010/11/12 John R Pierce <pierce(at)hogranch(dot)com>
> On 11/11/10 9:24 PM, Tom Lane wrote:
>
>> "Mark Mitchell"<mmitchell(at)riccagroup(dot)com> writes:
>>
>>> Is there are hard limit of 1600 that you cannot get around?
>>>
>> Yes.
>>
>> Generally, wanting more than a few dozen columns is a good sign that you
>> need to rethink your schema design. What are you trying to accomplish
>> exactly?
>>
>>
>
> indeed. I'd say a good read on 'data normalization' and the Third Normal
> Form would be in order.
>
> relational databases are *not* spreadsheets (and, for that matter,
> spreadsheets make lousy relational databases)
>
> if these 1600+ elements come from an ORM, you probably need to rethink your
> object model, as no sane object class should have that many members.
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
// Dmitriy.
From | Date | Subject | |
---|---|---|---|
Next Message | mbwl | 2010-11-12 07:27:05 | Re: Instructions/status of modpglogger |
Previous Message | John R Pierce | 2010-11-12 06:15:48 | Re: More then 1600 columns? |