• Yohan J (unregistered) in reply to clm
    clm:
    What I want to know is this: what was the random-number generator seeded with? Please, oh please, tell me they use the same seed every time -- it would make this WTF so much more ... err ... WTFier.

    Well, I'm the original submitter, and let me answer it to you. The random seed was never initialized on the code...

    Not only that, but that code appears, copy and pasted on many different parts of the system, each type of invoice is generated by a different file with no comments, (although the only thing that changes is the title and which table you use) and it is a marvelous of copy-and-paste reuse of code.

    And yes, there were cases of multiple values of the same key, due to concurrency I imagine, and the fact that some people would manually insert the codes on the table to generate some of the invoices types.

    I have a few other big wtfs I'm finding in this system and will probably send over. Let me just humour you a bit, one of the process had a function that took 12-16 hours to execute. Processing on the database about 50k rows, doing some validations. I changed the process to take 35 sec (and it can be speedied up a bit if I put my heart into it).

    There isn't a single key validation in the whole data base.. *criescriescries*cries

  • rupert.h (unregistered)

    Is there some reason to run the "random" search more than once? It seems one random jump into the DB with linear search for the next open record would maintain the quirky design and reduce the access time. You should also either extend your database by a factor of two or archive your defunct accounts.

  • Steve Ward (unregistered) in reply to Anon

    Why not?

    One of our clients started about fifteen years ago with project number 000001, they're now up to something like 000235.

    Admittedly each project can be up to several million $.

    Captcha: capio

  • Steve Ward (unregistered) in reply to Anon
    Anon:
    but why:
    Why aren't the invoice numbers allowed to be sequential ?

    Because you can't have a customer place order number 800234 one day and then order 800235 the next day and realize that you have no other customers! Same reason you don't start your invoice numbers at 000001.

    Why not?

    One of our clients started about fifteen years ago with project number 000001, they're now up to something like 000235.

    Admittedly each project can be up to several million $.

    Captcha: laoreet

  • Kris (unregistered) in reply to AnthonyB

    He could then persist this array in a DB table for future reference of used keys.... that would save time

  • KMag (unregistered) in reply to WayneCollins
    WayneCollins:
    JamesQMurphy:
    128 bits? You're essentially using GUIDs. A company that I worked at 10 years ago used GUIDs for their ID column -- SQL Server supports it.

    This was Oracle. I might have overlooked its GUID type if it had one. What I ended up doing was randomly generating two longs in C#, then concatting their "ToString()" output. Which, come to think of it, means that there was less than 128 bits of randomness, since multiple pairs of numbers yield the same concatted string.

    Oops.

    How many bits of state are kept by the PRNG you were using in C#? Given C#'s heritage (and a quick look at an Open Source CLR runtime implementation) I wouldn't be surprised Microsoft's C# runtime uses the BSD rand48() PRNG under the hood in its standard Random class. This gives you a maximum of 48 bits of entropy, no matter how many times you call it. (Unless you re-seed it, and re-seeding well in the middle of a database transaction is a bad idea.)

    This is a bigger oops than you not zero-padding the low order long.

  • Fuzz! (unregistered) in reply to DaveShaw

    Then there's only 1 ID left to find..

  • Furi (unregistered) in reply to GrandmasterB

    RTFM: http://au.php.net/manual/en/function.mt-rand.php

    I thought I'd see if anyone else mentioned the use of mt_rand. "Hey, at least it's faster than if he'd used regular rand()"

  • twobee (unregistered)

    Oh boy, that's so common ...

  • Trey Stout (unregistered) in reply to DaveShaw
    DaveShaw:
    Vollhorst:
    He could have run that code in multiple threads to speed it up!

    Argghh! That made me Laugh.

    So what happens when there are 999999 invoices in the database...??

    Dave

    They have enough money to recode the system?

  • Smokey (unregistered)

    I have to admit I did something like this once...it was a CS class project that I just wanted to get finished. However, I did comment on how crazy/crappy the code was. :)

Leave a comment on “The Quest for the Unique ID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article