Non sequential sequential numbers

  • Comments posted to this topic are about the item Non sequential sequential numbers

  • Nice question, thanks Steve

    ____________________________________________
    Space, the final frontier? not any more...
    All limits henceforth are self-imposed.
    “libera tute vulgaris ex”

  • read the question, knew the answer, clicked the wrong one! DOH!!!

    good reminder question though, ta

    ---------------------------------------------------------------------------------------
    The more you know, the more you know that you dont know

  • I went with the least surprising answer, that a function called "newsequentialid" would do what its called. They should have called "new_not_so_sequentialid".

  • I have never been convinced that using sequential guids is a viable architecture. Sure it reduces page splits caused by the randomness of a true guid but they are readily clear to be sequential and simple to guess the next one if you know an existing value already. Given that it seems like an identity makes as much sense. Still simple to guess, has very low page splits and takes up a fraction of the storage space. I know this is derailing the topic a bit but somebody convince me that the design of using a sequential id makes good sense? Or share some details of a time you used one where it really was a great choice?

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Sean Lange - Thursday, November 1, 2018 7:12 AM

    I have never been convinced that using sequential guids is a viable architecture. Sure it reduces page splits caused by the randomness of a true guid but they are readily clear to be sequential and simple to guess the next one if you know an existing value already. Given that it seems like an identity makes as much sense. Still simple to guess, has very low page splits and takes up a fraction of the storage space. I know this is derailing the topic a bit but somebody convince me that the design of using a sequential id makes good sense? Or share some details of a time you used one where it really was a great choice?

    The primary advantage I see is for Merge Replication.  Assuming all SQL Server nodes have unique MAC addresses, you avoid collisions while minimizing (if not avoiding) page splits.  Each database server has an "insertion point" for new records going on following a reboot, but at least it's only one insertion point per database server, not skipping all over the table.  I'll be honest that I haven't used Merge Replication, so I'm only bouncing the concepts around in my head, but I think it's an improvement for this scenario.

  • Replication and places where you might have multiple clients that need to get a series of values, but timing might cause issues. This makes sense, but it's a lot of overhead and *most* of the time numbers work fine. I tend to stick with identity for that reason

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply