• Crabs (unregistered) in reply to mxx
    mxx:
    fanha:
    ... So it grows exponentially from 0 at 0% load to infinity at 100% load; the performance would fall off sharply once it passed a particular threshold and it went exponential.

    Can't be bothered to do the maths right now, but it can't be growing exponentially to infinity; exponential functions don't go to infinity.

    so...the solution to lim(x->inf) f(x)=2^x is...what exactly?

  • Laslow (unregistered)

    A web registration form I inherited had this gem in it for generating confirmation numbers:

    $conf_num = rand(10000,32768);

    That's it. No checks, and of course there was no Unique ID on the database side. I caught it before any duplicate numbers were generated (this time around), but it shed light on issues they had the previous year were conference attendees ended up with duplicate registration numbers for some unknown reason....

  • (cs) in reply to Crabs
    Crabs:
    mxx:
    fanha:
    ... So it grows exponentially from 0 at 0% load to infinity at 100% load; the performance would fall off sharply once it passed a particular threshold and it went exponential.

    Can't be bothered to do the maths right now, but it can't be growing exponentially to infinity; exponential functions don't go to infinity.

    so...the solution to lim(x->inf) f(x)=2^x is...what exactly?

    well, infinity. However, you will notice that the algorithm in the OP will take infinite time for a finite n. In contrast to e. g. g(x) = 1/x, f(x) = 2^x will never attain infinity for any finite x, i. e. for any real number x, there is always a real number k such that k > 2^x.

    btw Anon, I hope your exponential functions are well at 11.

  • Goglu (unregistered)

    It's clearly a misinterpretation of the specs. The random generator was supposed to be used for the amount, not the invoice number.

  • Dennis (unregistered) in reply to mxx
    mxx:
    Crabs:
    mxx:
    fanha:
    ... So it grows exponentially from 0 at 0% load to infinity at 100% load; the performance would fall off sharply once it passed a particular threshold and it went exponential.

    Can't be bothered to do the maths right now, but it can't be growing exponentially to infinity; exponential functions don't go to infinity.

    so...the solution to lim(x->inf) f(x)=2^x is...what exactly?

    well, infinity. However, you will notice that the algorithm in the OP will take infinite time for a finite n. In contrast to e. g. g(x) = 1/x, f(x) = 2^x will never attain infinity for any finite x, i. e. for any real number x, there is always a real number k such that k > 2^x.

    btw Anon, I hope your exponential functions are well at 11.

    No. g(x)=1/x does not 'attain' infinity at x=0. It is undefined at x=0. (To quickly see why, look at what happens when x approaches 0 from below and what happens when x approaches 0 from above, you get two different results and there is no canonical choice, so g(x)=1/x is undefined at x=0).

    As g(x) is undefined at 0, then for all x>0 there is a real number k with g(x)<k. This is not a useful characterisation to make.

    The correct way to understand the 'infinite' behaviour of g(x)=1/x is to say that it is unbounded in any neighbourhood of 0. Or in other words, for any number N there exists a (probably small) number e such that for all 0<x<e we have g(x)>N.

    This statement is the mathematically rigorous way of saying g(x) tends to infinity as x tends to 0 (from above).

    Exponential functions behave in a similar way: f(x)=2^x is not defined at x=infinity in the same way that g(x) is not defined at x=0. But again for any number N there exists a (probably large) number e such that for all e<x<infinity we have f(x)>N.

  • edthered (unregistered) in reply to Windypundit
    Windypundit:
    Sutherlands:
    Buddy:
    May be a security issue. If the numbers are sequential, then if you have X, then you know X+/-N are likely valid as well. If they are random, then it's harder to guess them.

    I once worked at a place where a developer did a sequential numbering scheme, and lo and behold, someone could increment/decrement the ID in the URL and see other client's data. I had to patch in a random number validation code to hack a fix for that.

    Wait, clients could see other clients data by putting in the id, and your fix was to make the ids random? Didn't want to try server-side validation with some sort of permissions and login?
    I don't know what Buddy was doing, but adding random characters essentially gives each data item its own password.

    I've seen this where clients want to share their read-only access to their data with other other people who do not have credentials for the server. Think photo sharing: People post photos and then send the link to their friends or customers. The server has to provide the image to anyone with the right URL, because that is its purpose. However, users may start to complain if they figure out that their image URLs can be guessed by random strangers.

    The folks at SmugMug went through this a year or two ago. The guessability of URLs was obvious to anyone who thought about it, and users had the option of requiring authentication. Then one day it erupted as a "scandle" and SmugMug fixed it by adding random numbers to make it harder to brute force the URLs.

    Adding a random number to the url is only going to slow me down when looking for data for a particular sequence (ie. John's url is bar, so the next thing for John must be foo), not stop me from seeing data (Ohh... foo is cool, what's at bar?). A login is the only way to ensure that one customers data isn't viewable by any other customer.

  • Josh (unregistered)

    The Real WTF (among others) is the use of MySQL - naaay - MyISAM tables for invoice data.

    You should always use a real database - Postgres, Oracle, SQL-Server - for financial data. With MyISAM, if you sneeze one day or you look at the server the wrong way, your tables are corrupted.

    If you are forced at gunpoint to use MySQL for financial data, you should always use INNODB tables, never MyISAM. At least INNODB tables are transactional and have some resiliency against failure.

    The programmer who would know better than to use MySQL for this purpose would also know better than to create this WTF.

  • pizza (unregistered)

    the correct fix is to add more 9s!

  • n/a (unregistered) in reply to WayneCollins
    WayneCollins:
    themagni:
    WayneCollins:
    I must confess that I have written random ID generators in code to feed to a table.

    In my defense, the ID was 128 bits, so it would be a lot longer before you would expect a collision. Also, there was a primary key constraint on the ID, so you couldn't put in a duplicate record... which would bring you back to the ID generating loop, except much later in the growth of the table and with a round trip to the database every time.

    By the way, is there a good way to insert a row with a unique key and get back the key in a single request to an Oracle or MSSQL server?

    You could use the primary key, add each one sequentially, then if you don't want customers to know what their number is, hash it up and give them that number. Save the hash in the db and you can search by that, so you could write something like "select * from customers where hashID = value"

    I do PLC programming and I know that much.

    Yeah, that's great, until some other app, or multiple instances of the same app, want to insert things into the same table.

    I have no idea what you're getting at with this comment.. The person that you're responding to has the right idea.

  • (cs) in reply to kastein
    kastein:
    First. Or 758475th, if using this code... Seriously, how do people come up with nonsense like this and think it's a good idea? At least they should have the decency to do something like a "select id from invoices", then abuse that to find a random ID that isn't used in php, instead of doing a new query every single time they fail to find an unused ID.

    He probably thought it was really clever, and therefore fun to write and debug.

  • n/a (unregistered) in reply to n/a
    n/a:
    WayneCollins:
    themagni:
    WayneCollins:
    I must confess that I have written random ID generators in code to feed to a table.

    In my defense, the ID was 128 bits, so it would be a lot longer before you would expect a collision. Also, there was a primary key constraint on the ID, so you couldn't put in a duplicate record... which would bring you back to the ID generating loop, except much later in the growth of the table and with a round trip to the database every time.

    By the way, is there a good way to insert a row with a unique key and get back the key in a single request to an Oracle or MSSQL server?

    You could use the primary key, add each one sequentially, then if you don't want customers to know what their number is, hash it up and give them that number. Save the hash in the db and you can search by that, so you could write something like "select * from customers where hashID = value"

    I do PLC programming and I know that much.

    Yeah, that's great, until some other app, or multiple instances of the same app, want to insert things into the same table.

    I have no idea what you're getting at with this comment.. The person that you're responding to has the right idea.

    Wait, I think I just got it. You're not thinking that the application would generate the IDs are you? Every relational database I've ever worked with has the option of automatically incrementing integers for primary keys. Most are also multi-threaded (support atomic actions from simultaneous clients).

    If you really want to generate the IDs yourself, most modern DBs also support transactions.

  • justsomedude (unregistered) in reply to DaveShaw
    DaveShaw:
    So what happens when there are 999999 invoices in the database...??

    Dave

    You have to wait until the random number generator returns the one invoice number still available, 0-999999 is 1,000,000 possibles.

  • (cs) in reply to BottomCoder
    BottomCoder:
    HK47:
    WayneCollins:
    Anonymous:
    After your insert query, call this:

    SELECT LAST_INSERT_ID() FROM

    It will be thread safe if you're not using persistent connections.

    What part of "in a single request" is so hard to understand? I know in JDBC you can set an option on the query object to return the generated ID... but even still, why are you so psychotic about doing everything in one request? OH NO I HAVE A MINOR INEFFIENCY

    Because apparently someone has never done multithreaded programming...

    Multithreaded isn't necessarily a problem here. So far every database driver I've worked with has required all SQL calls to be made on the same thread that owns the connection. So even if you have multiple threads putting SQL calls into a queue for execution, you still only have one thread executing the calls. So there is no problem with needing two SQL calls as long as you ensure that they are queued together.

    If you want multiple concurrent SQL calls, you'd need a separate connection for each thread anyway and the previous paragraph would then apply individually to each thread.

    I could see an issue if you have multiple threads grabbing statements to execute from a single shared queue and end up having each call go to a different thread & connection. However, even that could be solved easily by allowing the queue to store groups of statements that can't be split across threads.

    Bottom line, multi-threading isn't an issue...

  • (cs) in reply to Josh
    Josh:
    The Real WTF (among others) is the use of MySQL - naaay - MyISAM tables for invoice data.

    You should always use a real database - Postgres, Oracle, SQL-Server - for financial data. With MyISAM, if you sneeze one day or you look at the server the wrong way, your tables are corrupted.

    If you are forced at gunpoint to use MySQL for financial data, you should always use INNODB tables, never MyISAM. At least INNODB tables are transactional and have some resiliency against failure.

    The programmer who would know better than to use MySQL for this purpose would also know better than to create this WTF.

    Oh please, people store this kind of stuff in ACCESS databases for crying out loud! What's wrong with MYSQL? =)

    Seriously, I agree with you on the MyISAM part most definitely. INNODB is also kind of a pre-requisite not only for transactions as you say but also for foreign keys. The first thought that came to my mind when I saw MyISAM in that definition was NO FOREIGN KEYS! I mean, I'm sure there are other tables that reference that Invoice ID and doing so without foreign keys is another WTF.

    But other than that, as long as stuff like that is stored properly using INNODB I don't see a problem with using MYSQL. Not everyone needs Oracle for crying out loud!

    I've got MySQL running next to me on the server here and it's been doing its job faithfully for over a year now with no problems.

  • (cs) in reply to Dennis
    Dennis:
    ...

    No. g(x)=1/x does not 'attain' infinity at x=0. It is undefined at x=0. (To quickly see why, look at what happens when x approaches 0 from below and what happens when x approaches 0 from above, you get two different results and there is no canonical choice, so g(x)=1/x is undefined at x=0).

    As g(x) is undefined at 0, then for all x>0 there is a real number k with g(x)<k. This is not a useful characterisation to make.

    The correct way to understand the 'infinite' behaviour of g(x)=1/x is to say that it is unbounded in any neighbourhood of 0. Or in other words, for any number N there exists a (probably small) number e such that for all 0<x<e we have g(x)>N.

    This statement is the mathematically rigorous way of saying g(x) tends to infinity as x tends to 0 (from above).

    Exponential functions behave in a similar way: f(x)=2^x is not defined at x=infinity in the same way that g(x) is not defined at x=0. But again for any number N there exists a (probably large) number e such that for all e<x<infinity we have f(x)>N.

    Of course you are right that 1/x does not "attain" infinity; Sorry, my maths vocabulary is slighty rusty. However, there is still an important distinction between the behaviour of 1/x and 2^x; unlike 1/x, 2^x is defined for any finite x. The question of it being defined or not at infinity is a moot point; to my knowledge, infinity is not generally considered part of the domain of any function. What's more, you cannot say that for any real number x there is a k such that k > 1/x, since this has no sense for x=0. However for k > 2^x it does have sense and is true. Consequently, this is a useful characterisation to make.

    To get back on topic, my point was that the id generation will take inifinite time for a finite number of occupied IDs (1000000), so the execution time cannot depend exponentially on the number of occupied IDs (at least it cannot be dominated by an exponential term near where it matters).

  • Ryan (unregistered) in reply to WayneCollins
    WayneCollins:
    A stored procedure could do it in one request. I should have done that, but I was still revolted by TSQL and PL/SQL and tried to do everything from a "real" language...

    In most cases there's a serious performance benefit for 'doing it in the database', especially when loading batches or doing something which can be done completely on the database.

    Makes the application code cleaner too, just throw a call into sp_DoSomethingInteresting and you're away.

  • (cs) in reply to Buddy
    Buddy:
    but why:
    Why aren't the invoice numbers allowed to be sequential ?

    May be a security issue. If the numbers are sequential, then if you have X, then you know X+/-N are likely valid as well. If they are random, then it's harder to guess them.

    I once worked at a place where a developer did a sequential numbering scheme, and lo and behold, someone could increment/decrement the ID in the URL and see other client's data. I had to patch in a random number validation code to hack a fix for that.

    Don't come and work anywhere near me. I may have to fire you on the spot.
  • (cs) 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.

    You know, back in the day I was evaluating help desk software for a network operations center, and my eventual pick was shot down by the chief propeller head because the ticket IDs started at 0.

    "We can't use that. Everybody will know that it's a new trouble ticket system if the numbers start at zero."

    "They're going to know it's a new system anyway, because only about fifty people even have our phone number, and prior to this they've never gotten any kind of incident number at all. What are you going to do, start the ticket numbers at ten thousand and hope nobody notices?"

    We wound up not implementing anything.

  • Sixnutz Esq. (unregistered) in reply to DaveK
    DaveK:
    icywindow:
    Or perhaps he should have taken advantage of Perl's relationship with PHP and put it into a hash function to get the number out, then increment until you find the next untaken number, after all, 1000000 is prime, right guys?
    Hmmm, you're not under the misapprehension that hash tables *have* to have a prime number of entries, are you? A commonly-held canard.

    A commonly held duck? I don't get it.

  • PaladinZ06 (unregistered) in reply to WayneCollins
    WayneCollins:
    I must confess that I have written random ID generators in code to feed to a table.

    In my defense, the ID was 128 bits, so it would be a lot longer before you would expect a collision. Also, there was a primary key constraint on the ID, so you couldn't put in a duplicate record... which would bring you back to the ID generating loop, except much later in the growth of the table and with a round trip to the database every time.

    By the way, is there a good way to insert a row with a unique key and get back the key in a single request to an Oracle or MSSQL server?

    Yes. Yes there is.

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

    Because that would eliminate the need for a random number generator.

  • GrandmasterB (unregistered)

    What I find humorous about this is that, while this system of generating random numbers and checking their existence is profoundly stupid, he deliberately chose to use 'mt_rand()' instead of rand() to get a 'better' random number.

  • (cs) in reply to mxx
    mxx:
    Dennis:
    ...

    No. g(x)=1/x does not 'attain' infinity at x=0. It is undefined at x=0. (To quickly see why, look at what happens when x approaches 0 from below and what happens when x approaches 0 from above, you get two different results and there is no canonical choice, so g(x)=1/x is undefined at x=0).

    As g(x) is undefined at 0, then for all x>0 there is a real number k with g(x)<k. This is not a useful characterisation to make.

    The correct way to understand the 'infinite' behaviour of g(x)=1/x is to say that it is unbounded in any neighbourhood of 0. Or in other words, for any number N there exists a (probably small) number e such that for all 0<x<e we have g(x)>N.

    This statement is the mathematically rigorous way of saying g(x) tends to infinity as x tends to 0 (from above).

    Exponential functions behave in a similar way: f(x)=2^x is not defined at x=infinity in the same way that g(x) is not defined at x=0. But again for any number N there exists a (probably large) number e such that for all e<x<infinity we have f(x)>N.

    Of course you are right that 1/x does not "attain" infinity; Sorry, my maths vocabulary is slighty rusty. However, there is still an important distinction between the behaviour of 1/x and 2^x; unlike 1/x, 2^x is defined for any finite x. The question of it being defined or not at infinity is a moot point; to my knowledge, infinity is not generally considered part of the domain of any function. What's more, you cannot say that for any real number x there is a k such that k > 1/x, since this has no sense for x=0. However for k > 2^x it does have sense and is true. Consequently, this is a useful characterisation to make.

    To get back on topic, my point was that the id generation will take inifinite time for a finite number of occupied IDs (1000000), so the execution time cannot depend exponentially on the number of occupied IDs (at least it cannot be dominated by an exponential term near where it matters).

    Well, I for one greatly enjoyed the maths discussion.

    Shame about all the database and threading crap.

  • (cs) in reply to Sixnutz Esq.
    Sixnutz Esq.:
    DaveK:
    icywindow:
    Or perhaps he should have taken advantage of Perl's relationship with PHP and put it into a hash function to get the number out, then increment until you find the next untaken number, after all, 1000000 is prime, right guys?
    Hmmm, you're not under the misapprehension that hash tables *have* to have a prime number of entries, are you? A commonly-held canard.

    A commonly held duck? I don't get it.

    Go to any English village green.

    The green will have a pond in it, or by it.

    The pond will most probably have ducks resident in it.

    English village greens are held "in common," unless subject to some hideous parliamentary Act of Enclosure.

    Thus, the ducks are held "in common."

    Simple, really. And now back to the real universe, in which words can have more than one meaning and are interpreted according to context. A difficult thing to achieve in SQL or PHP, but one that's oddly satisfying in English.

  • GrandmasterB (unregistered) in reply to Kermos
    Kermos:
    I've got MySQL running next to me on the server here and it's been doing its job faithfully for over a year now with no problems.

    Sheesh, we've been running ours for the better part of 7 or 8 years now without any significant problems. Just the occassional repair table when some idiot does something like unplugging the server thinking he was unplugging some other device.

  • StDoodle (unregistered)

    I won't even comment on the code implications of random invoice numbers; that's been covered.

    Some have pointed out that as a customer, it would look bad to place invoice number 800234 and later 800235, making one think they're the only customer. I've seen plenty of places that use a prefix for the client, so I would just assume in such a case that my client ID was the 800 prefix, and many others in business would assume this as well.

    What would make me do a double-take as a customer, and possibly reconsider doing business with a company, would be getting an invoice numbered 800234 one day, followed by 312789 a while later. Once, I might think they re-did their invoice codes. More than once, and I'd have serious doubts about how they ran their company.

  • LHC (unregistered) in reply to Greebo
    Greebo:
    In MSSQL, us an Identity column, and SCOPE_IDENTITY() (not @@IDENTITY) to retrieve the newly inserted ID from the current scope (@@IDENTITY ignores scope).
    Heh, I told you it had been awhile! :)
  • Mr A (unregistered)

    My personal favourite was in my first job - all primary keys where a 13 character string holding a time stamp in yyyymmddhhnnss format. When operations were 'too quick' (as they liked to call it) they simply waited one second and generated the next one. I skipped out of the building when I handed my notice in.

  • Albin (unregistered) in reply to vr602
    vr602:
    Buddy:
    but why:
    Why aren't the invoice numbers allowed to be sequential ?

    May be a security issue. If the numbers are sequential, then if you have X, then you know X+/-N are likely valid as well. If they are random, then it's harder to guess them.

    I once worked at a place where a developer did a sequential numbering scheme, and lo and behold, someone could increment/decrement the ID in the URL and see other client's data. I had to patch in a random number validation code to hack a fix for that.

    Don't come and work anywhere near me. I may have to fire you on the spot.

    He started off with a decent thought - predictability of invoice numbers - but then turned into a WTF of it's own. I almost think it is a clever joke.

  • Real-modo (unregistered) in reply to Jay Jay
    Jay Jay:
    A single statement, outside of the database? Ugh. Don't do it. Stored procs are the way to go if you're using Oracle. Well, they are IMHO.
    But but but but ... that gets you encapsulation, performance, security! Where's the fun in that?
  • Milligan (unregistered) in reply to mxx
    mxx:
    Dennis:
    ...

    No. g(x)=1/x does not 'attain' infinity at x=0. It is undefined at x=0. (To quickly see why, look at what happens when x approaches 0 from below and what happens when x approaches 0 from above, you get two different results and there is no canonical choice, so g(x)=1/x is undefined at x=0).

    As g(x) is undefined at 0, then for all x>0 there is a real number k with g(x)<k. This is not a useful characterisation to make.

    The correct way to understand the 'infinite' behaviour of g(x)=1/x is to say that it is unbounded in any neighbourhood of 0. Or in other words, for any number N there exists a (probably small) number e such that for all 0<x<e we have g(x)>N.

    This statement is the mathematically rigorous way of saying g(x) tends to infinity as x tends to 0 (from above).

    Exponential functions behave in a similar way: f(x)=2^x is not defined at x=infinity in the same way that g(x) is not defined at x=0. But again for any number N there exists a (probably large) number e such that for all e<x<infinity we have f(x)>N.

    Of course you are right that 1/x does not "attain" infinity; Sorry, my maths vocabulary is slighty rusty. However, there is still an important distinction between the behaviour of 1/x and 2^x; unlike 1/x, 2^x is defined for any finite x. The question of it being defined or not at infinity is a moot point; to my knowledge, infinity is not generally considered part of the domain of any function. What's more, you cannot say that for any real number x there is a k such that k > 1/x, since this has no sense for x=0. However for k > 2^x it does have sense and is true. Consequently, this is a useful characterisation to make.

    To get back on topic, my point was that the id generation will take inifinite time for a finite number of occupied IDs (1000000), so the execution time cannot depend exponentially on the number of occupied IDs (at least it cannot be dominated by an exponential term near where it matters).

    This discussion is getting less and less funny as it goes along. It is, however, still a little funny. It appears to be asymptotic humour.

  • Windypundit (unregistered) in reply to edthered
    edthered:
    Adding a random number to the url is only going to slow me down when looking for data for a particular sequence (ie. John's url is bar, so the next thing for John must be foo), not stop me from seeing data (Ohh... foo is cool, what's at bar?). A login is the only way to ensure that one customers data isn't viewable by any other customer.
    Not sure I follow. If the server has foo at

    http://mydata.wtf/000000001_CB34D6853C8C4BD3B37A30AD433349AC.html

    and bar is at

    http://mydata.wtf/000000002_96B8CF3D1E994E32BDF78E95F17B3BED.html

    knowing foo doesn't get you to bar. I could have a billion URLs like this, and if they're cryptographically strong, guessing gets you nowhere (except for very large values of guessing).

    You can't get bar without knowing the URL, just like you can't login without a password. It's a reasonable system for giving out fine-grained access that can be useful under specialized circumstances---e.g. customized download URL's when you buy software.

  • (cs) in reply to WayneCollins
    WayneCollins:
    Anonymous:
    After your insert query, call this:

    SELECT LAST_INSERT_ID() FROM

    It will be thread safe if you're not using persistent connections.

    What part of "in a single request" is so hard to understand?

    Not necessarily any part.

    SomeConnection.CommandText="begin tran; insert into xxx values (?, ?, ?); select scope_identity();commit tran"

    Add some parameters to this (we try to be injection free, right?) and you are home free. One insert followed by one select. All in one transaction. Using scope_identity() will ensure that you get the right thing everytime. @identity will happily return the last identity inserted on some foreign table in some trigger, or even from another connection.

    Amateurs...

  • (cs) in reply to Albin
    Albin:
    vr602:
    Buddy:
    but why:
    Why aren't the invoice numbers allowed to be sequential ?

    May be a security issue. If the numbers are sequential, then if you have X, then you know X+/-N are likely valid as well. If they are random, then it's harder to guess them.

    I once worked at a place where a developer did a sequential numbering scheme, and lo and behold, someone could increment/decrement the ID in the URL and see other client's data. I had to patch in a random number validation code to hack a fix for that.

    Don't come and work anywhere near me. I may have to fire you on the spot.

    He started off with a decent thought - predictability of invoice numbers - but then turned into a WTF of it's own. I almost think it is a clever joke.

    I hope it was a joke, but am not convinced. Random numbers and obfuscation are not convincing security aids. They just lead to random and obfuscated bugs.

  • DrunkCoder (unregistered)

    Hmm ... where it belonged ... PRODUCTION! ;)

  • Anon (unregistered) in reply to StDoodle
    StDoodle:
    Some have pointed out that as a customer, it would look bad to place invoice number 800234 and later 800235, making one think they're the only customer. I've seen plenty of places that use a prefix for the client, so I would just assume in such a case that my client ID was the 800 prefix, and many others in business would assume this as well.

    Yes, but you're thinking like a rational person, try thinking like a manager instead.

  • Zerbs (unregistered) in reply to LHC
    LHC:
    Been awhile, but maybe...

    @@IDENTITY returns the last inserted identity value

    Just have your row identfied as an identity

    I believe that you should use Scope_Identity() function in SQL Server. That way you won't get the value of a different table if a trigger does an INSERT into another table with an IDENTITY column.

  • Buddy (unregistered) in reply to Albin
    Albin:
    vr602:
    Buddy:
    but why:
    Why aren't the invoice numbers allowed to be sequential ?

    May be a security issue. If the numbers are sequential, then if you have X, then you know X+/-N are likely valid as well. If they are random, then it's harder to guess them.

    I once worked at a place where a developer did a sequential numbering scheme, and lo and behold, someone could increment/decrement the ID in the URL and see other client's data. I had to patch in a random number validation code to hack a fix for that.

    Don't come and work anywhere near me. I may have to fire you on the spot.

    He started off with a decent thought - predictability of invoice numbers - but then turned into a WTF of it's own. I almost think it is a clever joke.

    URLs before: ...?ID=[sequential] URLs after: ...?ID=[sequential]&VC=[large number picked at random associated internally in DB with ID]

    The original network had problems with secure session handling so entire site was stateless - no cookies, no sessions, all info passed via URL or form post.

    The original code was really messed up so this was the quickest solution that required the fewest modifications. Still allowed for URLs to be shared within organizations, providing deep linking was enabled.

    Also, was a junior at the time. When you have higher-ups yelling, you do what shuts them up the fastest.

  • NH (unregistered)

    Sometimes you want unpredictable ID:s to avoid users to circumvent the application by predicting the ID of the next/previous record.

    But you still want an unique index on it to avoid trouble.

  • (cs) in reply to Sixnutz Esq.
    Sixnutz Esq.:
    DaveK:
    icywindow:
    Or perhaps he should have taken advantage of Perl's relationship with PHP and put it into a hash function to get the number out, then increment until you find the next untaken number, after all, 1000000 is prime, right guys?
    Hmmm, you're not under the misapprehension that hash tables *have* to have a prime number of entries, are you? A commonly-held canard.

    A commonly held duck? I don't get it.

    Well, I canardly explain it better than it's already explained in the other thread at http://forums.thedailywtf.com/forums/p/11152/193432.aspx#193432.
  • Chad (unregistered) in reply to but why

    Maybe that number leaks to the outside, so your competitor can order twice, subtract, and know the rate you do business.

  • (cs)
    1. The random number thing made me seriously go "WTF" out loud. At work.

    2. I would love to see an invoice where my invoice number came in the form of a GUID - that would be awesome.

  • Mads Bondo Dydensborg (unregistered) in reply to WayneCollins
    By the way, is there a good way to insert a row with a unique key and get back the key in a single request to an Oracle or MSSQL server?

    Oracle, of the top of my head, declare the key as autoincrement, do something like insert into bar ( id ) values ( id_sequence.nextval ) returning id_sequence.currval into foo

    or something like that. You should be able to look it up :-)

  • (cs)

    Wow. At least my predecessors had the, uh, decency, to do "SELECT MAX(id)+1 FROM some_table;" to get the next free identity.

    Every day I go to work, I die a bit more.

  • (cs) in reply to hikari
    hikari:
    Wow. At least my predecessors had the, uh, decency, to do "SELECT MAX(id)+1 FROM some_table;" to get the next free identity.

    Every day I go to work, I die a bit more.

    Did they have the decency to wrap that in a transaction or something?

  • (cs) in reply to Brett
    Brett:
    This reminds me of a sorting algorithm that a friend invented (in jest). He called it a "bumble sort".

    The code randomly looked at an array location and compared it's contents to the location immediately after. If it was lower than the first, it swapped the location's contents and repeated the process on another randomly selected array location.

    So how did it know when it was done? Did it just run forever and give you a higher and higher degree of confidence of sorting?

    Perhaps it did a full scan of the array after every flip to see if it was now in order? That seems the most logical solution for such a sorting algorithm.

    Also, bogosort.

  • (cs) in reply to hatterson
    hatterson:
    Brett:
    This reminds me of a sorting algorithm that a friend invented (in jest). He called it a "bumble sort".

    The code randomly looked at an array location and compared it's contents to the location immediately after. If it was lower than the first, it swapped the location's contents and repeated the process on another randomly selected array location.

    So how did it know when it was done? Did it just run forever and give you a higher and higher degree of confidence of sorting?

    Perhaps it did a full scan of the array after every flip to see if it was now in order? That seems the most logical solution for such a sorting algorithm.

    Also, bogosort.

    Also, Intelligent Design Sort. The most efficient sort algorithm yet discovered. Or do I mean invented?
  • (cs) in reply to DaveK
    DaveK:
    hatterson:
    Brett:
    This reminds me of a sorting algorithm that a friend invented (in jest). He called it a "bumble sort".

    The code randomly looked at an array location and compared it's contents to the location immediately after. If it was lower than the first, it swapped the location's contents and repeated the process on another randomly selected array location.

    So how did it know when it was done? Did it just run forever and give you a higher and higher degree of confidence of sorting?

    Perhaps it did a full scan of the array after every flip to see if it was now in order? That seems the most logical solution for such a sorting algorithm.

    Also, bogosort.

    Also, Intelligent Design Sort. The most efficient sort algorithm yet discovered. Or do I mean invented?
    I would have gone with 'designed' or 'created'
  • FELIPE (unregistered) in reply to Bob

    PLEASE DEFINE NONTRIVIAL

  • (cs) in reply to Anon
    Anon:
    Yes, but you're thinking like a rational person, try thinking like a manager instead.
    What, you mean like an imaginary person? (Let's get back to the maths discussion -- it's far more interesting.)

    Since I stopped wearing my roo-fur-lined KangaFoil cap around ten years ago, I've had this persistent feeling that there's somebody out there who's trying to tell me what to do. I can't help myself. I keep asking these imaginary people, "Why?" and "Don't you realise how stupid that is?" and "You do realise that this will kill people, don't you. And not just worthless poor immigrants, either" and "What do you want to be when you grow up?"

    I mean, it's embarrassing. Obviously, I pay no attention to the imaginary answers (I might be credulous, but I'm not that credulous), but just the fact that I believe these phantoms are there is troubling.

    Actually, I believe that "thinking like a manager" is an oxymoron. Not just because managers are an imaginary irritant, but because, by definition, they are incapable of thinking.

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

Log In or post as a guest

Replying to comment #:

« Return to Article