Re: Using bits to store information in the database.

Laura,

    I would strongly discourage this approach. There are several issues relating to using bits to store more meaningful data. 1) The column is not self documenting. When a new developer or support tech has to deal with this column, the chances of misunderstanding and misuse are greatly increased.
2) Each application accessing the column will have to perform a translation. You are dependent upon each application performing the same logic. This can be handled using a common called subroutine, but... 3) Changes to meaning, adding new statuses, etc. will require changing application code and perhaps a new release of multiple applications

    This is the reason for lookup tables and RI. If you need to add a new flag value, you insert a record into the table. No new application code, no release (depending upon how your organization handles data changes). You can store a single character in the column and only go to the lookup table for a short and/or long description.

    In terms of storage, a CHAR(1) column will actually require less storage than a NUMBER(x).

Daniel W. Fink
http://www.optimaldba.com

laura pena wrote:

> 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
> ------------------------------------------------------------------------
> Do you Yahoo!?
> The New Yahoo! Search
> <http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com> -
> Faster. Easier. Bingo.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Daniel W. Fink
  INET: optimaldba_at_yahoo.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).