> This bitand stuff sounds like a nightmare to
> maintain.
You mean the Oracle data dictionary :-)
Nothing like a:
select * from dba_views
where view_name like 'DBA%'
to convince you of the wonderful merit to bitand'ing
your entire database :-)
- "Deshpande, Kirti" <kirti.deshpande_at_verizon.com>
wrote: > In the COBOL and mainframe world, some of our
> 'clever' developers used 'ALTER' statement that
> dynamically changed the target of the 'GO TO'
> statement branching. Reading/Understanding the code
> without knowing the data was almost impossible.
> Clever programming trick?
> Job Security?
> Anything else?
> All of the above..
> It was a nightmare to maintain the code.
> This bitand stuff sounds like a nightmare to
> maintain.
>
> Now you know my age ;)
> - Kirti
>
> -----Original Message-----
> Sent: Wednesday, May 07, 2003 1:38 PM
> To: Multiple recipients of list ORACLE-L
>
>
>
> From a database maintenance and code maintenance
> perspective,
> this is a bad idea.
>
> If comes under the heading of 'clever code' that a
> developer can look
> at and say "Ain't I clever". I've done it, we've
> probably all done it
> at some time.
>
> It was a bad idea when I did it, and it remains a
> bad idea. Do it and you
> will regret it as long as you have to work with the
> system.
>
> Do yourself a favor and properly model this, then
> build a database that
> gives you flexibility and no limitations.
>
> Jared
>
> On Wednesday 07 May 2003 09:32, laura pena wrote:
> > 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
> > Jonathan Gennick <jonathan_at_gennick.com>
> wrote:Wednesday, May 7, 2003,
> > 10:22:06 AM, you wrote: lp> Looking for advise on
> storing bits in the
> > Oracle
> > lp> database column.The scenario goes like this:
> define
> > lp> column statusFlag NUMBER(x)statusFlag can
> represent the
> > lp> following: verified set to 1nonverified set to
> > lp> 10confirmed set to 100non confirmed set to
> 1000audited
> > lp> set to 10000 I believe this gets my point
> accross.... So
> > lp> here are my questions: What is the largest
> amount of bit
> > lp> I can set for a NUMBER(x)?
> >
> > When you go from 1 to 10 to 100 to 1000, you
> aren't working
> > your way up in terms of bits, but rather in terms
> of decimal
> > digits. NUMBER columns are stored in some sort of
> decimal
> > format. I believe the largest possible NUMBER is
> NUMBER(31),
> > but check the manuals to be sure. That would give
> you 31
> > positions: 1, 10, 100, 1000, etc.
> >
> > What is the reason for going down this path? Have
> you
> > considered alternatives? You might find it easier
> to us a
> > CHAR(31) column, in which case you could use
> SUBSTR to
> > address each, individual flag. For example:
> >
> > SELECT *
> > FROM my_table
> > WHERE SUBSTR(x,23)='T';
> >
> > I suppose you could even create function-based
> indexes to
> > help such queries.
> >
> > If you really want to work in terms of bits, then
> you need
> > to think in terms of 1, 2, 4, 8, etc.
> >
> > Best regards,
> >
> > Jonathan Gennick --- Brighten the corner where you
> are
> > http://Gennick.com * 906.387.1698 *
> mailto:jonathan_at_gennick.com
> >
> > Join the Oracle-article list and receive one
> > article on Oracle technologies per month by
> > email. To join, visit
> >
>
http://four.pairlist.net/mailman/listinfo/oracle-article,
> or send email to
> > Oracle-article-request_at_gennick.com and
> > include the word "subscribe" in either the subject
> or body.
> >
> >
> > 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 lp> NUMBER? I can
> > guess one.. wasted space. Thanks in advanced,-Lizz
> >
> > lp> ---------------------------------
> > lp> Do you Yahoo!?
> > lp> The New Yahoo! Search - Faster. Easier. Bingo.
>
>
>
>
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> --
> Author: Deshpande, Kirti
> INET: kirti.deshpande_at_verizon.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).
>
Connor McDonald
web:
http://www.oracledba.co.uk
web:
http://www.oaktable.net
email: connor_mcdonald_at_yahoo.com
"GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day"
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: =?iso-8859-1?q?Connor=20McDonald?=
INET: hamcdc_at_yahoo.co.uk
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).
Received on Wed May 07 2003 - 22:56:54 CDT
