mine too... I had to maintain code like that. In a true "what goes
around comes around" story, when I left that place to go to my next
job, it turned out that the programmer who had wanted to "play" with
all the possibilities in COBOL was also working there. and I had
control over some of his work...
ya just don't annoy a New Yorker. <EG>
- "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@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).
>
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Rachel Carmichael
INET: wisernet100_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).
Received on Wed May 07 2003 - 15:39:34 CDT
