From: | "Tille, Andreas" <TilleA(at)rki(dot)de> |
---|---|
To: | |
Cc: | PostgreSQL SQL <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Turning column into row |
Date: | 2002-05-22 14:36:22 |
Message-ID: | Pine.LNX.4.44.0205221629000.8932-100000@wr-linux02.rki.ivbb.bund.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Wed, 22 May 2002, Wm. G. Urquhart wrote:
> Not at all if you have for example 6 properties:
>
> Prop 1 = 1 ;
> Prop 2 = 2 ;
> Prop 3 = 4 ;
> Prop 4 = 8 ;
> Prop 5 = 16 ;
> Prop 6 = 32 ;
You are right, I have exactly 6 properties ;-) and actually for this
kind of application it is perfectly all right to proceed this way.
I do not put all of them not in separate columns but into one
column with the concatenated string
Prop 1/Prop 3/Prop 6/
(and strip the remaining '/' afterwards).
While this solution is kind of a hack it fits my needs so far.
> The user will select the properties applicable to the Item; so for this
> example the new item has Properties 1, 3 and 6. These property values are
> added to give a total of 37. This is the value stored in the table column.
>
> Once you have the rows you can then && the Properties column to see if a
> property is set. I know this works as I've done it before in Oracle,
> Oracle even supports bitwise predicates. But I'm not sure if PostgreSQL
> does.
>
> if (Item.Column && Prop1)
> Do this ;
> else
> Property Not supported... ;
> end if ;
I see no reason why this should not work - but I even see no real
advantage to store a bitfield instead of just the concatenated string
in a temporary table which is removed afterwards anyway.
Thanks for the further hint
Andreas.
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2002-05-22 14:45:39 | Re: [SQL] Bug with Daylight Savings Time & Interval |
Previous Message | Wm. G. Urquhart | 2002-05-22 14:06:31 | Re: Turning column into row (More...) |