• LCrawford (unregistered)

    Get it to pass a unit test. Winning! Ship!

  • Little Bobby Tables (unregistered)

    pass the brain bleach

  • bvs23bkv33 (unregistered)

    unique-comment-0a

  • Sally Flynn (unregistered)

    carves Guid.NewGuid() into a clue-by-four and goes hunting for the developer who wrote the abomination in the article

  • (nodebb)

    If you can increment guids, then you should be able to add, subtract, multiply and divide them, too.

  • Klaus (unregistered) in reply to Mr. TA

    Actually... no. Incrementing doesn't require arithmetic operations to be defined. It just requires, that for each element of the domain a successor is defined; While for number domains this typically is related to addition, it doesn't need to be.

    For instance, you may define the increment of "A" to be "B" on the domain of latin letters, but it isn't necessary to define the meaning of "A+A" or other arithmetic operations. Neither does a defined addition operation imply a meaningful definition of "increment". The only case I can think of, where addition and increment are somewhat naturally related are really integers.

  • gnasher729 (unregistered)

    Just why this might be useful: If you start with one truly random GUID and then create further GUIDs in sequential order (and others do the same thing), you reduce the tiny, tiny likelihood of collisions even further. There is a price to pay: IF you have collisions you will probably have a lot of them.

  • (nodebb)

    Wouldn't it have just been easier to split on the dashes, parse it as base-16 integers, do the math (with overflows), and format it back out to text?

    Although, I wonder why they needed them to be sequential? I've used them specifically to avoid implicit ordering of auto-increment fields. In those cases, a timestamp or some other form of deliberate ordering was employed...

  • Dave (unregistered)

    If you want sequential numbering, why are you using GUIDs? Why not just use, I dunno, sequential integers? Obviously that has potential problems with race conditions, but if the sequence of IDs is important, that's also a problem with using GUIDs.

  • misterdoubt (unregistered)

    Well, NEWSEQUENTIALID() is a thing. But I'm pretty sure it doesn't look like this under the hood.

  • juloo (unregistered)

    I love the error handling. "Error", "error" and ex.Message. Their code base must be so broken.

  • (nodebb) in reply to Dave

    We use seq. GUIDs generated by the RDBMS as an indexable primary key for our data. Our data is synchronized between DBs on 3000 user PCs and one central DB hosted by us. Sequential integers are not unique between computers, but GUIDs by definition are.

    Sequential does not necessarily mean that each number (or GUID) in the sequence be incremented by one, just by a logical difference. E.G., the Fibonacci sequence. As long as they increase (or decrease) in a sequence, then the IDs are indexable and are usable as an index in an RDBMS.

  • Darron (unregistered)

    No comments about "return ex.Message"?

    Now that's an odd guid...

  • Rod (unregistered) in reply to gnasher729

    you reduce the tiny, tiny likelihood of collisions even further

    I believe the incremented GUID has the same probability of colliding with some other pre-existant value as a truly random one does.

  • sizer99 (google)

    So The Real WTF (TM) is that this method exists at all, much less his implementation and broken error handling.

  • Gnasher729 (unregistered) in reply to Rod

    The expected number of collisions cannot be changed. But if you and I both create a million sequential GUIDs, the chance of any collision is much lower. The chance of lots of collisions is much higher.

    It’s like buying 1000 lottery tickets, all with the same numbers. The chances of winning are a lot lower than with 1000 random tickets, but you have a chance to win 1000 prices.

  • Dave (unregistered) in reply to Developer_Dude

    As long as the order ids are allocated matters, you have to allocate sequentially. In which case whether the sequence increments by one or not is irrelevant. But natural numbers seem more, well, natural to me.

  • Lucas Ieks (google)

    I wonder why the "else" was commented. Maybe it didn't work.

  • (nodebb)

    nHibernate has a generator method for identity called Guid.Comb. Basically, the first one is done using one method and then subsequent ids are "incremented" for some definition of increment. It is a faster way to generate when you are inserting a bunch of new records at the same time.

  • Sole Purpose of Visit (unregistered) in reply to Zenith

    I suspect it would be easier to simply call a function to ask for a new GUID. You know, like GUID.NewGuid().

    But that's just me, and you were clearly being sarcastic anyway.

    (If you really, really, want to perform Peano-like arithmetic on GUIDs, of course, you could simply store them in a Dictionary with added ordinal goodness. I don't imagine that we're going to run out of 64-bit integers any time soon.)

  • Barf4Eva (unregistered) in reply to Developer_Dude

    DevDude, are you clustered on your PK? If not, I think that can be acceptable. Otherwise, it is a bit of space consumption to make that your clustered key and then having that cost on all your indexes.

    Everyone else, There are cases where Sequential GUID will make sense, and there is plenty of support for such things in RDBMSes, such as SQL Server. You can find articles suggesting potential merits of doing this in the app layer (moreso than the DB layer. Mertis such as not round-tripping, although there is more than one way to skin this cat)

    Here are some interesting articles, discussing pros, cons, etc: https://blog.greglow.com/2017/10/26/newsequentialid-nice-try-but-missed-the-target/ https://www.brentozar.com/archive/2014/08/generating-identities/

  • (nodebb) in reply to Klaus

    You haven't been around for long enough. People have tried adding A+A for sure.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Or you could stick a sequence integer on the end of the GUID. Which with this bozo would probably cause problems the first time a tenth increment was needed, as the string went from "-9" to "-10", and sorted after "-1".

  • (nodebb) in reply to Barf4Eva

    IIRC we do have a few clustered indexes - but most (as in almost all) are not clustered. The space that they consume is not an issue in our schema; we have non-indexed data columns that consume many orders of magnitude more space than a GUID (or the indexes based on them) and there is no way around that (no, it cannot be compressed - it already is).

  • Klaus (unregistered) in reply to Mr. TA

    I didn't realize the most obvious example: Dates.

    It is perfectly possible to define an increment for dates (e.g. "next day", "next week", "next month"...), but adding, subtracting, multiplying or dividing dates has no meaningful definition.

  • Wizofaus (unregistered) in reply to juloo

    Except it's not just "error" - it's the original input with its last character replaced with the word "error".

  • (nodebb)

    If you want to have "sequential GUIDs" - why not make the already long string a tiny bit longer by just appending a sequential number?

Leave a comment on “Ternt Up GUID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article