• KattMan (cs) in reply to R.Flowers
    R.Flowers:

    Anonymous:
    I thought maybe the Tantalus reference was one about a book I had many many years ago, called, if I recall, the Tasks of Tantalus, which was a kids puzzle book, sort of like The Egyptian Jukebox, sorta.  Anyway, I can't really find a reference online anymore about it, so I might have imagined it.

    Wikipedia's got you covered

    Tantalus' punishment, now proverbial for temptation without satisfaction, was to stand in a pool of water beneath a fruit tree with low branches. Whenever he reached for the fruit, the branches raised his intended meal from his grasp. Whenever he bent down to get a drink, the water receded before he could get any. Over his head towers a threatening stone, like that of Sisyphus.

    Of course, it may also refer to the Tantalus Field from the Star Trek episode "Mirror, Mirror." It was a machine that ended careers, also. Of course, it ended your career by ending your life, but the principle is the same.

    And wasn't Tantalus referecend in HellRaiser 2 when Good Ol' Uncle Jack was complaining about not getting to the women that were inticing him all the time?

    Perhaps Pinhead has taken up Enterprise Application Development, it would explain all the code I've been seeing lately.

  • KattMan (cs) in reply to Gary
    Anonymous:

    Long ago last century, I worked for a "computer vendor", one of the companies referred to as the Seven Dwarfs ------

    I was assigned maintenance of a program that was littered with statements such as

    size = size * 1.0;

    Being naive, I asked "WTF" and was told "We Don't Know". The programmer who did that has been gone for many years. We took them out once and the results were disasterous.

     Fortunately I learned my lesson early in my career.  Some questions have no answers and are not even worth answering.

    Classic example of an INT being converted to a FLOAT.

  • minion (unregistered) in reply to themagni
    themagni:

    oh for farks sake

    It's a delay? Calls to that table are delays?

    What does this code do, summon Cthulhu? 

    > SELECT chant FROM summoning WHERE ancient='Cthulhu';
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

     

    All your base our belong to Cthulhu! 

  • Just another programmer (unregistered) in reply to Papa Lazarou

    Your story is a prime example why you should have a DEV and/or QA enviroment that's a mirror of production.  Luckily, we do and we recently went on a database cleanup binge and found a couple of old lookup tables we didn't think we being used for anything.  However we quickly found in the QA enviroment that they were in fact were being used.

  • 1337 (unregistered)

    Alex Papadimoulis:
    Make sure to look for the first article in the "CodeSOD: Code Snippet Of the Day" series a bit later tonite.
     

    wouldn't that make it "CodeSON: Code Snippet Of the Night"?

     

    captcha - giggity, giggity

  • JamesCurran (cs) in reply to maht

    Anonymous:
    cowboy_k:
    Yes it will. However, for many applications, the added overhead of storing data this way (MS SQL Server calls it a "clustered index", and usually creates one on the primary key if you define the PK in Enterprise Manager) is far, far outweighed by the performance gain in searching for a record matching a particular PK.
     
    It says "Table Data" in the OP. Not index data.

    A MS SQL Server "Custered Index" does in fact order the phyisical table data to the order of the index.

    However, I do not believe the Enterprise Manager automatically creates a clustered index for a primary key (Unfortunately, I don't have MSSQL install on the PC to test it out).

    And, a clustered index on the primary key will only give you a performance gain over having no index at all.  A standard index would almost always be faster, particular on tables with a large row size and a small key size (It would require one additional disk read to get the actual data, but it would have had to look through far less data to find the record).   Clustered indexes are most useful, not on PK fields (where you'd usually be looking for a single record), but on fields where you'd be seeking a range of values (like date/time fields).  In fact, the best place to use them (assuming that you'd need to lookup on this field) is on the RowCreatedDate field (since all new records would automatically go to the end, there would never be a need to reorder the data, which is the chief problem with clustered indexes)

  • Papa Lazarou (unregistered) in reply to Just another programmer

    Anonymous:
    Your story is a prime example why you should have a DEV and/or QA enviroment that's a mirror of production.  Luckily, we do and we recently went on a database cleanup binge and found a couple of old lookup tables we didn't think we being used for anything.  However we quickly found in the QA enviroment that they were in fact were being used.

    You're absolutely right.  We're going to get one.  Right after we get a mirrored development environment. *cry*  *self-harm*
     

  • quephird (cs) in reply to ammoQ

    I got that one beat. Our group supports a number of home-grown Oracle forms, one of which mysteriously caused the dreaded ORA -00600 one day. The cause: one of the blocks was based on... wait for it... the DUAL table, and allowed SELECT, UPDATE, INSERT, and DELETE. (The block displayed a bunch of derived data, and the original developer (a consultant btw) presumably had no idea how to SELECT it all without basing the block on a real table.) A user on this particular day decided to delete everything in the block and committed, thinking (understandably) that the only data that would be deleted was that displayed on the form. The DBA upon discovering the db session and form that caused the Oracle error decided in response to...<drumroll>... add two rows to DUAL. (I know... give him a break: the table name would appear to suggest otherwise.) Needless to say, the database was still throwing ORA-00600's. Finally, we convinced the DBA that the DUAL table indeed was a core part of the Oracle database, was supposed to be owned by SYS, and that it had only one row.

  • neoecs (unregistered)

    They just want to be able to brag about that their application runs the latest in database technology. ;)

  • anonymous (unregistered) in reply to xix

    Yeah, I think the reference should be to Sisyphus, not Tantalus. Tantalus was up to his neck in water but couldn't drink; Sisyphus kept rolling the same rock up the same hill every day only to see it roll down the hill at night. There's a book by Albert Camus called The Myth of Sysphus that definitely isn't a children's book...but all of the paperback Camus from the 70s had weird-looking clown/mime guys on the cover, so maybe that is what you are thinking of.

  • Greyhound (unregistered)

    They found out where I work. They are watching me.

  • foonly (unregistered) in reply to Wait a minute...
    Anonymous:
    Anonymous:
    Anonymous:

    Every day thedailywtf has been getting closer to describing what I work on.  Today you hit it right smack bang in the middle.

    What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

     An example from my project was a table called something like "usa_company" which contained a single column called "company" (varchar(20) of course) and a single row saying something like "ACME Suchandsuch".  One of the team piped up "we can drop this right" and i was so sure that there was no possible use for the table that I told them to delete it without even checking the code.


    We got a tech support call withing 30 seconds.

    Wait...to get a tech support call in 30 seconds....you must have been dropping tables on a PRODUCTION database. Ummm, I'm sorry but you deserved that.

    Our users aren't smart or coordinated enough to reach for the phone, let alone look up a number, let alone dial it, let alone complain over it all in 30 seconds.

     We got a support call from a customer that had canceled their maintenance contract 5 years ago. The caller said there was a sign taped to the front of the box with an arrow pointing to a light.  The sign said "If this light goes on, call ..."  The light went on, so they called.  We ended up making a lot of money off the "a la carte" support call pricing.
     

  • savar (cs) in reply to Why not?
    Anonymous:
    Just Another WTF:

    Well you know its always handy to be able to count to 4...

    as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

    > SELECT * FROM _dummy

    Results: 4,1,2,3

    You are assuming it's actual integer data. Could be strings: '1', '2', '3', '4', '-1', 'File Not Found', ...

    The table is intended for declaring constants to use in base-4 math operations using digits 1-4 instead of 0-3:

    DECLARE 
      operand1 number(1);
      operand2 number(1);
      sum number(2);
    BEGIN
      SELECT number FROM _dummy INTO operand1 WHERE number=1;
      SELECT number FROM _dummy INTO operand2 WHERE number=4;
      sum := pkg_base4_math.add(operand1, operand2);
      dbms_output.put_line('..And the WTF sum is..  .. '||sum||'!');
    END;
    /
    

    Duh.

     Yes, it's a slow day here. Bonus points to whomever posts the implementation of pkg_base4_math.add().

  • Zygo (unregistered) in reply to maht
    Anonymous:
    cowboy_k:
    Anonymous:
    merreborn:
    Just Another WTF:

    Well you know its always handy to be able to count to 4...

    as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

    > SELECT * FROM _dummy

    Results: 4,1,2,3

    True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

     Are you sure about that ?

    Wouldn't it make inserts O(n) instead of O(1) ?

     


     

    Yes it will. However, for many applications, the added overhead of storing data this way (MS SQL Server calls it a "clustered index", and usually creates one on the primary key if you define the PK in Enterprise Manager) is far, far outweighed by the performance gain in searching for a record matching a particular PK.
     

     
    It says "Table Data" in the OP. Not index data.

    Binary tree and appending inserts sounds faster but I guess they know more about it than me.

     

     

     

    Oops, in my previous post I thought we were talking about the BDB backend in MySQL, not clustered indexing.

    In the BDB backend, storage is actually roughly in order of insertion; however, the *only* way to access rows is in primary key order (if you don't have a primary key defined, one will be supplied for you) regardless of the physical order of rows in the table on disk.  That means that "select sum(some_column) from tbl" runs in O(n*log(n)) time.   This (and its write-ahead undo-and-redo transaction log implementation) is why BDB is the slowest backend by far on MySQL.

    In clustered index implementations (where a table is physically laid out on disk in the order of some index, usually the primary key), it is often possible to defer the reordering of table data.  So you can do a lot of inserts at O(1) or O(log(n)) each, which would temporarily put the new rows out-of-order in the table but still searchable within the index.  Then later you would do a recluster of the table which does one single O(n*log(n)) reorganization of the table data.  After that, you can do "SELECT blah, blahFROM table ORDER BY primary_key" and it will run as fast as your disks can feed data to the CPU. 

    To justify the costs involved the tables usually have to be huge, rarely modified, and large portions of the table searched in many queries, especially queries that contain aggregate functions.

  • KattMan (cs) in reply to savar
    savar:
    Anonymous:
    Just Another WTF:

    Well you know its always handy to be able to count to 4...

    as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

    > SELECT * FROM _dummy

    Results: 4,1,2,3

    You are assuming it's actual integer data. Could be strings: '1', '2', '3', '4', '-1', 'File Not Found', ...

    The table is intended for declaring constants to use in base-4 math operations using digits 1-4 instead of 0-3:

    DECLARE 
      operand1 number(1);
      operand2 number(1);
      sum number(2);
    BEGIN
      SELECT number FROM _dummy INTO operand1 WHERE number=1;
      SELECT number FROM _dummy INTO operand2 WHERE number=4;
      sum := pkg_base4_math.add(operand1, operand2);
      dbms_output.put_line('..And the WTF sum is..  .. '||sum||'!');
    END;
    /
    

    Duh.

     Yes, it's a slow day here. Bonus points to whomever posts the implementation of pkg_base4_math.add().

    I'd give this a shot but I have <gasp> actual work to do </gasp>.  But I bet it has something to do with standard 4-4 beats in music.

     

  • My Lord! (unregistered) in reply to ewhac

    Anonymous:
    It looks like Wil Wheaton being strangled by a pizzaria tablecloth.

    Thank you.  You have now officially replaced my image of Wil Wheaton's pepperonis being mangled by a pack of Klingon targs.

  • My Lord! (unregistered) in reply to marvin_rabbit
    marvin_rabbit:

    Probly didn't search for:

     SELECT * from /055/144/165/155/0x6D/131

    Ya gotta watch out for those things. 

    Probably missed the views: _vw_dummy, _vw_u_dummy, _vw_u_big_dummy, and finally....

    _vw_oh_elizabeth_help_me_now_I'll_be_coming_to_you_soon_this_is_the_big_one_ohhhhhh1001101eleventy1

  • Zetetic (unregistered) in reply to themagni

    What does this code do, summon Cthulhu?

     

    Silly human. Cthulhu cannot be summoned by a mere SQL statement, or any "object oriented" nonsense like

     
    Cthulhu.call() 

     

    no, the Elder God will rise up from his abyssal slumber only when properly invoked using IBM 1401 machine language, consisting solely of branch instructions, and then only after 616 debugging sessions, done in the dark of the vernal equinox, and THEN only after sacrifice of a virgin (one of which is generally easy to find in most development shops).

  • Tim (unregistered) in reply to Saladin
    Saladin:

    The Real WTF(tm) is re-compiling code after you've just added comments.

     

    I can tell you've never made a mistake, or had the whole build broken because someone else checked in some code without compiling because "all I did was change some comments". 

  • My Lord! (unregistered) in reply to Jimbo
    Anonymous:

    vecctor:
    I found the part about getting first hired by a smaller firm interesting. Is that usual? Around where I went to school, all the big companies were snatching people out of college so they could mold them into the type of developer they wanted.

     It's that way for me, although I'm in Michigan, home to the greatest unemployment in the states.

    No need to worry if Mr. Amway Quixtar Scam Devos gets the gov spot.

  • triso (cs) in reply to Rick
    Rick:
    Anonymous:

    He searched the code and didn't find all the things that obviously depended upon this table?

    Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

     

    I believe that he did find all the occurences.<font face="VERDANA" size="1">n</font>

    The problem could have been a timing issue.  

    <font size="+1">N</font>ow there's a scary thought.
  • SwordfishBob (unregistered) in reply to Jason
    Anonymous:

    Well, Oracle has the Dual table:

    Select * from Dual:
    This is because you can't just do SELECT 'Some String stuff'; it has to be from a table. Thus they look like: SELECT 1, 2 FROM Dual.

    Imagine what would happen if someone added a row, or deleted the single row in this table...


    In IBM DB2 there's always a dummy available:

    db2 => select * from sysibm.sysdummy1
    IBMREQD
    -------
    Y
    1 record(s) selected.

    but now you can just use the VALUES command to avoid involving a table:
    db2 => values (7)

    1
    -----------
            7

    1 record(s) selected.

  • gl (unregistered) in reply to Erik

    Just pure speculation here, but Oracle has a Fine-Grained Auditing module that implements the equivalent of a SELECT trigger, which could be executing any kind of code.  Some other enterprisey databases may have the equivalent, too.

  • grg (unregistered) in reply to SM

    >I think he means to comment out that module, not add comments to it.

     

    Oh, another youngster.   There are languages where COMMENTS are syntactic elements.  For instance, in good old COBOL, a COMMENT is a statement.  so if you had:


     IF PRESIDENT_SALARY EXCEEDS MY_SALARY TIMES TEN THEN
                 ADD 1000 TO MY_SALARY.

     and then changed it to:

     IF PRESIDENT_SALARY EXCEEDS MY_SALARY TIMES TEN THEN
                 COMMENT I WONDER HOW LONG THIS WILL STAY IN THE CODE?.
                 ADD 1000 TO MY_SALARY.

    ... then probably unintendedly the IF statement now controls the COMMENT, not the ADD statement.  What a language!

     

     

     

     

  • Highland FS (unregistered) in reply to Tei
    Anonymous:
    Anonymous:
    Rick:
    Anonymous:

    He searched the code and didn't find all the things that obviously depended upon this table?

    Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

    I believe that he did find all the occurences.

    The problem could have been a timing issue.  

    So you're guessing that "select * from _dummy" is an enterprisey equivalent to "sleep(30)" - priceless!

    No.  Bue people often write in a "experimental mode" where fast trial and error changes on the code search the "magic" value that not-crash the program. This own we can see code like this one:

     for (t=3;t< max -pad +22;t++){ //22 work, 21 crash and 23 corrupt all data. Please use 22.
        if (! t %7) buff[t] |= 1;
    }
     

    You guys don't get it do you!!!  THERE'S _NO_ HOPE!  NO LIGHT AT THE END OF THE TUNNEL.  Not because of a train.  It's because you are in a cave.  A deep cave.  And you don't know the way out.  You can here strange echo's, and you keep thinking you can figure the way out, BUT YOU CAN'T.

     

    Geeze, where do they get these guys?  Google?
  • Arancaytar (cs)

    "watching their spirit get completely crushed by the monstrosity that has become their daily life."

    I am one of them. :/

    The inherited code I've had to work with has driven me to tears on occasion - tables without primary keys which, long if-else trees substituting as switches...

    Fortunately it's usually small enough to just rip apart in a fit of fury and rewrite from scratch in a long afternoon. That's about the only consolation.

  • Dazed (unregistered) in reply to ammoQ
    ammoQ:

    Several years ago, I had such a table - called DUMMY - with one column - DUMM - that would contain one or more lines with the value 'X'. Droping the table would have crashed the whole application...

    The reason for that was the behaviour in Oracle's SQL*FORMS version 3. In Forms, you could call stored procedures, or write DML statements in the triggers (event handlers), but the only way to make it do a COMMIT was to change a database-bound-field. Unfortunately, I didn't want to use database-bound-fields - for several reasons - so every form had a datablock bound to DUMMY, with a field bound to DUMM. There was a procedure "dummy_commit" like this:

    go_block('DUMMY'); 

    exectute_query; 

    :DUMMY.DUMM := 'X';

    commit;

    And of course the table had a second field called README which contained a brief bit of text explaining what it was there for.

    Umm, I guess not. Simple ideas like that seem to be far beyond the ability of most programmers.

  • Ian (unregistered) in reply to Jason

    Yeah, That's dumber than dirt, not supporting the

    SELECT 'foo' 

    Syntax the rest of the world does.... 

     I vote for the theory that they were testing the pooled database connection.  That makes me fear them least.

  • Gene Wirchenko (cs) in reply to Zetetic
    Anonymous:

    What does this code do, summon Cthulhu?

     Silly human. Cthulhu cannot be summoned by a mere SQL statement, or any "object oriented" nonsense like

     Cthulhu.call() 

     no, the Elder God will rise up from his abyssal slumber only when properly invoked using IBM 1401 machine language, consisting solely of branch instructions, and then only after 616 debugging sessions, done in the dark of the vernal equinox, and THEN only after sacrifice of a virgin (one of which is generally easy to find in most development shops).

    Bah!  All you need is the correct sacrificial parameters.  You can not go cheap though.  You have to use call-by-reference sacrifices.  Call-by-value references just do not have that ummph that Elder Gods require.

    Sincerely,

    Gene Wirchenko

     

  • VGR (cs) in reply to Papa Lazarou
    Anonymous:

    What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

    I think the more common name for it is "spaghetti code."

  • GoatCheez (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Anonymous:

    What does this code do, summon Cthulhu?

     Silly human. Cthulhu cannot be summoned by a mere SQL statement, or any "object oriented" nonsense like

     Cthulhu.call() 

     no, the Elder God will rise up from his abyssal slumber only when properly invoked using IBM 1401 machine language, consisting solely of branch instructions, and then only after 616 debugging sessions, done in the dark of the vernal equinox, and THEN only after sacrifice of a virgin (one of which is generally easy to find in most development shops).

    Bah!  All you need is the correct sacrificial parameters.  You can not go cheap though.  You have to use call-by-reference sacrifices.  Call-by-value references just do not have that ummph that Elder Gods require.

    Sincerely,

    Gene Wirchenko

     

     

    OMFG GENE MADE A POST!!! Thank god another sane head is making comments, even if they are in jest ;-P 

  • Anonymous (unregistered) in reply to SwordfishBob

    And in Informix Dynamic Server you can query virtual "collection derived tables":

    SELECT "SomeString" FROM TABLE(LIST{0})

  • DrCode (cs) in reply to Highland FS
    Highland FS:

    You guys don't get it do you!!!  THERE'S _NO_ HOPE!  NO LIGHT AT THE END OF THE TUNNEL.  Not because of a train.  It's because you are in a cave.  A deep cave.  And you don't know the way out.  You can here strange echo's, and you keep thinking you can figure the way out, BUT YOU CAN'T.

    It is dark here, and you are likely to be eaten by a Grue. 

  • OpBaI (cs)

    The Real WTF is that nobody said "Five is right out!" yet...

  • HitScan (cs)
    jdieter:

    Rob is the idiot. Who "takes things out" of a production system BEFORE they know what the thing does.

    Am I the only one who thinks these WTF's are getting too damn wordy! I guess Alex fancies himself a writer, not a coder. Oh well.
     

    Short answer: Yes. Yes, you are all alone. It's getting darker and darker... 

    Long answer: I finally figured out why you're so against the story WTFs; you're illiterate. Let's explore:
    1. Rob dropped the table and then tested his app, which didn't work. The Behemoth sucks out loud.
    2. Papa Lazarou dropped a production table and everyone has been dogpiling him long past the limits of good measure. his development environment sucks manberries, though it's likely not his fault.

  • HitScan (cs) in reply to OpBaI

    OpBaI:
    The Real WTF is that nobody said "Five is right out!" yet...

    They already passed 4 - joke ruined. :(

     

  • ammoQ (cs) in reply to Dazed
    Anonymous:
    ammoQ:

    Several years ago, I had such a table - called DUMMY - with one column - DUMM - that would contain one or more lines with the value 'X'. Droping the table would have crashed the whole application...

    The reason for that was the behaviour in Oracle's SQL*FORMS version 3. In Forms, you could call stored procedures, or write DML statements in the triggers (event handlers), but the only way to make it do a COMMIT was to change a database-bound-field. Unfortunately, I didn't want to use database-bound-fields - for several reasons - so every form had a datablock bound to DUMMY, with a field bound to DUMM. There was a procedure "dummy_commit" like this:

    go_block('DUMMY'); 

    exectute_query; 

    :DUMMY.DUMM := 'X';

    commit;

    And of course the table had a second field called README which contained a brief bit of text explaining what it was there for.

    Umm, I guess not. Simple ideas like that seem to be far beyond the ability of most programmers.

    No, it hadn't. And it didn't need one. The whole application was so fscked up that no other programmer would dare to touch it.

  • reptar (unregistered) in reply to HitScan
    HitScan:

    2. Papa Lazarou dropped a production table and everyone has been dogpiling him long past the limits of good measure. his development environment sucks manberries, though it's likely not his fault.

     

    Dave, you wanna buy pegs?  I got pegs! 

  • Lankiveil (cs) in reply to Anonymous Coward 1.0
    Anonymous:

    you must have been dropping tables on a PRODUCTION database. Ummm, I'm sorry but you deserved that.

    Yeah, this.

  • Anonymous (unregistered) in reply to Anonymous Coward 1.0
    Anonymous:

    you must have been dropping tables on a PRODUCTION database

     

    meh ... I like to drop bowling balls on my production databases ....
    it's fun!
     

  • utu (cs) in reply to Jason
    Anonymous:

    Well, Oracle has the Dual table:

    Select * from Dual:

    | DUMMY |

    ----------------

    |  X  |

     
    This is because you can't just do SELECT 'Some String stuff'; it has to be from a table. Thus they look like: SELECT 1, 2 FROM Dual.

    Imagine what would happen if someone added a row, or deleted the single row in this table...

     

     Actually, it's there to ascertain that you receive one row as a result, no more, no less. If you wanted to do some calculation using SQL, you could of course do

    SELECT 1+2 FROM USERS; (of course, assuming you had a table named "USERS"), but I for one wouldn't like to waste the system's resources to return me ~35000 rows of "3" when all I was interested in was to get the (one) result I asked for.

    And for those who wonder why anyone on their right minds would name a table consisting of only one row DUAL need to think of it as "the dual element of the query"; the queried "field(s)" is the other element. Without both, the query will not be executed. Ok... I made that up just now :)

  • gwenhwyfaer (cs) in reply to Zygo
    Zygo:

    Primary keys need to have indexes (or reasonable facsimile) to implement the unique constraint.  The two popular data structures that are typically used for this purpose are btrees (O(log(n))) and hash tables (O(n) with a very small constant--you divide n by say 16 million and search that number of rows in the hash bucket).

    Just to be picky - hash tables don't store anything in order; hashes are supposed to be scattered over the key space. Storing in key order implies a tree - and O(log n) performance.

    Sorry. :)

  • brandon (unregistered)

    How about this for naming conventions...

    SELECT
        [ USER ID ],
        [USER  NAME],
        [TIMESTAMP ]
    FROM
        [GENERAL USERS]

     

    Columns and table names.....

     
    Typically, a good signpost of bad things to come is dishevelled database design. Then comes the potpourri of mixed up code in the applications like the Behemoth. But what perpetuates all of this is misguided management that thinks that by shipping the work out as fast as you can, and then fixing the bugs as you go along the way (which is a widely adopted philosophy) contributes greatly to what Martin Fowler has termed as the I.T. deficit. The technical/programming debt incurred by cutting corners. Once we reach a critical mass, this deficit takes on a whole life of its own and at this point, the bugs are too entrenched to be fully fix. What would be needed is a complete re-write but the risk and cost that that often carries proves too daunting for most CFOs and CIOs.
     

  • Gorobei (unregistered) in reply to xix

    Don't worry, the uneducated poster was thinking of Sisyphus (the rock up the hill pushing dude,) not Tantalus (the fruit and water just out of reach dude.)

  • AW (unregistered)

    Could be a poor man's row generator.

  • Chris (unregistered)

    Alex,

    Many thanks or the Laugh Of The Day !

    Now my personal story...

    20 years ago i was responsible for maintenance of a large Pascal program in an hospital. At that time, the system i was working on had no step by step debuger, so it was all editing source code with Emacs like editor, compile, run, and manually, or better "visually" check the validity of the result. Very poor documentation but very readable code, the program design was quite good, very modular, understandable variable and function names, so it was not really a painful job i thought, in no more than one hour i could do the minor changes requested by management, then i could read any IT or SciFi book for the next 7 working hours. So the job was very cool !

     Well, that's what i thought for the first two weks... Until i spent one day and a half on one single function of 30 lines or so that was not behaving as it was expectd, whatever i changed. After the first day of trials and failures,  was completely and absolutely puzzled, begining to write test programs to find the bug in the compiler...

    The day after; after one more hour i was ready to give up, until i did something with absolute non-sense, out from a desperate mind, i could not even EXPLAIN why i was doing it, something as an intuition, almost a prayer : i commented out the whole function, launched the compilation which surpsisingly succeeded then the program which behaved as before, while it should have crashed miserabily !

    Then i understood what happened : the previous guy responsible for the maintenance was afraid to break something and not being able to recover. So he cut and paste thousands lines of code, and duplicated them in the very same file, with one version being commented out, using /* at the begining and */ at the end.

    At this time everything was green on the Hercules powered screen, so no way to visually distinguish comment from actual code. And all the modifications i did was indeed in the ineffective commented portion of the file. When i explained what had happened to the older developers around, everybody noded in a non surprised way, i simply could not believe they were not complaining about the lack of design guideline or documentation or else. Business as usual !

    Feeling depressed, one month after i was starting a job at a different employer, not a maintenance one. And since i always managed to avoid ANY maintenance job ever since, at least i debug my own bugs :o)

    My true story,

    Christian

  • Chris (unregistered) in reply to Greg

    LOOOOOOOOOOOLLLLLLLLL !!!!

    Greg, you are kidding, aren't you ?  First, i NEVER witnessed a successful project lauch first shot, even though QA did their job. Somebody always fogot something somewhere in the transition process.

    Then, after a while, you can be sure that the test system and the production plateform are out of synch ! Hopefully the daily backup avoids losing more than a day of work ;o)

    Christian 

  • RadHard (unregistered) in reply to Gorobei

    Anonymous:
    Don't worry, the uneducated poster was thinking of Sisyphus (the rock up the hill pushing dude,) not Tantalus (the fruit and water just out of reach dude.)

    A more appropriate metaphor would be the cleaning of the Augean Stables.

     

  • David Cameron (unregistered) in reply to Ayende Rahien

    That is why you have temp tables and table variables

     eg

    CREATE #temp
    (Num Int IDENTITY
    Value VarChar(40))  -- whatever

    INSERT INTO #Temp
    (Value)
    SELECT Value
    FROM MyTable
    ORDER BY MyValue

    SELECT *
    FROM #temp

  • icelava (cs) in reply to rmr

    rmr:
    So what was it actually using "_dummy" for?  We need more details here.
    Probably the count on the number of past managers/architects fired from the project.

    Or, on a more serious note, could be a table used to test the connection properly, like with ad-hoc SQL statements, before any real SQL statements are passed through the connection.
     

Leave a comment on “Crash Test _dummy”

Log In or post as a guest

Replying to comment #:

« Return to Article