RE: Using bits to store information in the database.

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Wed, 07 May 2003 09:37:00 -0800
Message-ID: <F001.00592975.20030507093700@fatcity.com>

verified = 1
not-verified = 2
confirmed = 4
not confirmed = 8  

so, verified+confirmed = 1+4 = 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 12:32 PM
To: Multiple recipients of list ORACLE-L

The reason to use bit flags suggested by developers ... are that we can represent multiple check options.
In my example
verified and confirmed could be check.
So if verified was 1 and confirmed was 01 then the following bits would be set 11.  

I see both advantages and disadvantages to this. The alternative approach would be to use varchar2(1) and have columns represent each. I heard 32 entries would be max with this approach. If we used a long 64 bits but that seems like a lot of wasted space.  

Fom the developers view point they can reference a database column once and perfom the bit translation on the client side.  

I am wondering if alternatively I could create a stored procedure to do the samething.  

Seems like an interesting design decision.

-Lizz

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: Rajendra.Jamadagni_at_espn.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).



text/plain attachment: ESPN_Disclaimer.txt

Received on Wed May 07 2003 - 12:37:00 CDT