I concede your point btw -- my 12 year old car has the combination lap/shoulder belt :)
--- Cary Millsap <[EMAIL PROTECTED]> wrote: > Assuming reliability in something that's inherently unreliable > creates > danger. The experienced learn to ignore naming standards, as you > describe below. The inexperienced--the very people that the standards > were ostensibly designed to help--are tricked by them. > > My point is that naming standards that embed un-enforced information > end > up being more of an unintentional dirty trick than an aid. It's kind > of > like those old cars with the automatic shoulder restraint, but you > had > to clip the lap belt yourself. It was no less effort to clip the lap > belt than to clip a shouder/lap belt combination. If you wore the > shoulder belt but not the lap belt, you were actually more likely to > die > in an accident than if you wore neither. The only things the > automatic > lap belt accomplished were: > > * Made the car more expensive to produce and purchase > * Annoyed experienced drivers because it was slow > * Annoyed experienced drivers because it often hit you on the head > * Killed more inexperienced drivers > * Allowed your Congressman to appear that he cared for your safety > > > Cary Millsap > Hotsos Enterprises, Ltd. > http://www.hotsos.com > > Upcoming events: > - NCOAUG Training Day, Aug 16 Chicago > - Miracle Database Forum, Sep 20-22 Middlefart Denmark > - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 > Dallas > > > > -----Original Message----- > Carmichael > Sent: Wednesday, July 31, 2002 6:13 AM > To: Multiple recipients of list ORACLE-L > > Cary, > > As a DBA, I tend not to rely on names anyway because I believe that > documentation etc is out of date and incorrect two seconds after it > is > completed. > > But for my developers, it does help to have some sort of convention > when they read explain plans, especially if I also impose the rule > that > no one can create anything except me. > > And then there is the unanswerable argument of "corporate policy > dictates we have naming standards" :) > > Rachel > > --- Cary Millsap <[EMAIL PROTECTED]> wrote: > > Rachel, one of the SQL statements in our Clinic that people find > the > > hardest to optimize is one that has a thing that looks like > > "id_number = > > 10000" in the where clause. "id_number" is the table's primary key, > > yet > > the query spends 20 seconds executing a full-table scan. Any > guesses? > > > > It's because "id_number" was actually defined as a varchar2 column. > > Oracle's implicit type coercion converts the predicate into > > "to_number(id_number) = 10000". Presto: the PK index is useless. > > > > This and dozens of other unnecessarily pathological problems await > > people who try to embed too much information into their names. > > > > > > Cary Millsap > > Hotsos Enterprises, Ltd. > > http://www.hotsos.com > > > > Upcoming events: > > - NCOAUG Training Day, Aug 16 Chicago > > - Miracle Database Forum, Sep 20-22 Middlefart Denmark > > - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 > > Dallas > > > > > > > > -----Original Message----- > > Carmichael > > Sent: Tuesday, July 30, 2002 8:09 PM > > To: Multiple recipients of list ORACLE-L > > > > I can see your point, In the data warehouse we are building here, > the > > modeler is planning on prefixing tables with the type of table (D_ > > for > > dimension tables, F_ for fact, etc) > > > > Hm, you mean we have to go back and revisit the naming standards > that > > they developed? Can I please suffix the column names with an > > indicator > > of the datatype? :) > > > > The biggest problem is that most management wants "naming > > standards"... > > > > > > Rachel > > > > > > --- Cary Millsap <[EMAIL PROTECTED]> wrote: > > > I just think it's a waste. You can tell by context what kind of > > thing > > > a > > > thing is. For example, consider: "select a.flarg from bloing a > > where > > > a.croopoo > 7". This can be understood by syntactical context > (even > > > with > > > the nonsense names), without having to rename "bloing" to > > > "bloing_table". > > > > > > Most of the embedding of type names into object names that I've > > seen > > > has > > > been implemented by users who were inexperienced at the time they > > > created the standard. They were worried that without embedding > the > > > type > > > name into the object name, they might forget what kind of object > it > > > was. > > > ...Most such naming conventions become onerous over time, long > > after > > > you > > > find out that you can find the type of something in the data > > > dictionary, > > > but after it's too late to save the thousands of extra characters > > of > > > typing that'll waste people's lifespans over time. > > > > > > In my old OFA paper, I made a joke about how we don't embed type > > > names > > > into object names in daily life, with just a few exceptions > (Billy > > > the > > > Kid, Winnie the Pooh, Atilla the Hun, and the younger family > > members > > > of > > > the old Walton Family TV show are a few examples). If you have > both > > a > > > dog and a child named "Rex," though, it's probably a good idea to > > > expect > > > them both to come when you call. With SQL, though, I can't think > of > > a > > > case in which it's not easy to tell by syntactic context what > kind > > of > > > thing you're talking about... > > > > > > > > > Cary Millsap > > > Hotsos Enterprises, Ltd. > > > http://www.hotsos.com > > > > > > Upcoming events: > > > - NCOAUG Training Day, Aug 16 Chicago > > > - Miracle Database Forum, Sep 20-22 Middlefart Denmark > > > - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 > > > Dallas > > > > > > > > > > > > -----Original Message----- > > > Carmichael > > > Sent: Tuesday, July 30, 2002 4:49 PM > > > To: Multiple recipients of list ORACLE-L > > > > > > Cary, > > > > > > you said > > > "* Don't embed the object type in the object's name. I used to > see > > > this > > > all the time with tablespaces called XYZ_TS, indexes called > > > IND_THING, > > > and so on." > > > > > > what's your logic behind that? > > > > > > Rachel > > > > > > > > > > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
