Oracle-L: RE: Using bits to store information in the database.

From: Kevin Lange <klange_at_ppoone.com>
Date: Wed, 07 May 2003 10:12:33 -0800
Message-ID: <F001.00592B5A.20030507101233@fatcity.com>

Dealt with the same thing in the past and it always came up to bite us in one form or another.

Our solution was a seperate table with a Type column and a Value column. In our case it delt with training. Typically, for an individual, our data looked like this:

SSN			TRAINING_TYPE	TRAINING_TAKEN
123-45-6789		PROCEDURE 1			Y
123-45-6789		PROCEDURE 2			N
123-45-6789		PROCEDURE 4			Y
987-65-4321		PROCEDURE 1			Y
987-65-4321		PROCEDURE 3			N

This , in our old design used to be represented by

123-45-6789	1001
987-65-4321	0001

Unfortunately, when we added a new type of training we had to alter the logic to add a new byte to the data.

With the new design, they just add a record with a new Traininig Type to the Database.

Maybe you could use something along those lines.

-----Original Message-----

Sent: Wednesday, May 07, 2003 11:57 AM
To: Multiple recipients of list ORACLE-L

Then wouldn't this be easier to maintain/query/document/etc if that column were in a separate table with a one-to-many join?

Under our old manufacturing system (written in DIBOL!), we had a column in the partmaster of 128 bits. Any part could be in any number of 128 buckets. Not only was this very difficult to program, but a showstopper when the 129th bucket was proposed.

Do yourself a favor. Dump the column into another table!

My $.02,
Rich

Rich Jesse                        System/Database Administrator
rich.jesse_at_qtiworld.com           Quad/Tech International, Sussex, WI USA

-----Original Message-----

Sent: Wednesday, May 07, 2003 11:07 AM
To: Multiple recipients of list ORACLE-L

most common use of bit-logic is to combine multiple "attributes" which may occur in combinations. e.g. in UNIX read-write-execute permissions as in chmod can be defined as ...

READ        100    (4)
WRITE       010   (2)

EXECUTE 001 (1) which would accomodate all 6 combinations of R-W-X into 3 bits. the point is they COULD EXIST IN ANY COMBINATION ...

in this case, i agree with raj completely regarding use of integers. first of all,
"states" like "verified" and "non-verified" , "confirmed" and "non-confirmed"
does not seem to co-exist ( at least, as far as their names go ). this itself does
not justify the use of bit-logic ( even before performance impact is considered ).

moreover, if the "states" themselves transition in a particular order, use of
integers are much more suitable to track them. ( it gets "confirmed" only after
it is "verified" ... and so on and so forth )

imho, storing bit-logic in columns should be the last resort, if at all ...

-----Original Message-----

Sent: Wednesday, May 07, 2003 10:57 AM
To: Multiple recipients of list ORACLE-L

I think using integers rather than bits will be easier on your where clause. It might look nice, but it will probably be a killer for performance when you starting using bit logic in queries.

I'd prefer but YMMV

Verified         1
Non-Verified     2
Conformed        3
non-confirmed    4
Audited          5

Raj

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art !

-----Original Message-----

Sent: Wednesday, May 07, 2003 10:22 AM
To: Multiple recipients of list ORACLE-L

Looking for advise on storing bits in the Oracle database column. The scenario goes like this:

define column statusFlag NUMBER(x)
statusFlag can represent the following:

verified set to 1
nonverified set to 10
confirmed set to 100
non confirmed set to 1000
audited set to 10000

I believe this gets my point accross.... So here are my questions:

What is the largest amount of bit I can set for a NUMBER(x)?

How can one set and retrive the information in Oracle based on bits being set?

Are there any draw backs from using too large of a NUMBER? I can guess one.. wasted space.

Thanks in advanced,
-Lizz
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Jesse, Rich
INET: Rich.Jesse_at_qtiworld.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services


---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Kevin Lange
INET: klange_at_ppoone.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services


---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message