Home Forums SQL Server 2008 SQL Server 2008 - General Primary key or not to primary key, that is the question RE: Primary key or not to primary key, that is the question

  • March 20, 2013 at 8:52 am

    #1598951

    TheSQLGuru (3/20/2013)

    tafountain (3/20/2013)

    TheSQLGuru,

    I did not intend to spark a debate 🙂 but here are my responses.

    TheSQLGuru (3/19/2013)

    1) if you are worried with space, GUIDs have no place in your system.

    This statement is a little unsubstantiated. GUIDs are fine, sure they're larger than INT but they fulfull requirements that an INT cannot. For example we need to maintain uniqueness across servers. A GUID does this for us. Yes, they have drawbacks but I would not totally exclude them as an option because of them.

    TheSQLGuru (3/19/2013)

    2) why aren't you using NEWSEQUENTIALID??

    These do not provide uniqueness across tables, let alone across servers.

    TheSQLGuru (3/19/2013)

    3) Your PK on the parent does a clustered index on the NEWID, since you didn't specify one.

    Is this a question or a statement? Not sure what you're trying to communicate.

    TheSQLGuru (3/19/2013)

    4) You are fragmenting the heck out of your nc indexes on those GUIDs.

    Yes - this is very true. However most of the indexes are defragmented in under 30 seconds (most under 10 seconds) during our nightly maintenance.

    TheSQLGuru (3/19/2013)

    5) Did I mention that GUIDs SUCK yet?!? Oh, and for multiple systems, you can almost ALWAYS come up with a simple multi-part numeric arrangement that is guaranteed to be unique across all systems. I have used a tiny/smallint ServerID and integer identity construct at numerous clients to eliminate GUIDS they "HAD to have", always with GREAT effect.

    Ok, now you have my interest :). I wouldn't mind understanding your implementation.

    1) As I already said, you can (and I have several times) maintained uniqueness across multiple servers with an int identity and a separate ServerID field (tiny or small int) that is used as the compound PK for the table. Given that ServerA ALWAYS uses 1 for ServerID, ServerB ALWAYS uses 2 for ServerID, etc, you are GUARANTEED to NEVER get duplicate PK values with that 5 or 6 byte PK (instead of the SIXTEEN bytes of a GUID).

    2) I believe you are wrong in stating that NEWSEQUENTIALID isn't UNIQUE. The only time it would not be is if there is no NIC on the server. Got many of those lying around?? I haven't seen one in the 20+ years I have been with databases, 15 of them as a SQL Server consultant. Here is the reference, which comes directly from SQL Server Books Online: http://msdn.microsoft.com/en-us/library/aa379322(VS.85).aspx

    3) My "PK is clustered index" is a statement. If you simply define a PK on a table it is clustered by default unless you override that with explicit syntax to make it non-clustered.

    4) It may not matter (much) on your system, but the extra bytes required for a GUID over other datatype(s) or compound keys REALLY make a difference on systems with any reasonable number of rows.

    Regarding this:

    3) My "PK is clustered index" is a statement. If you simply define a PK on a table it is clustered by default unless you override that with explicit syntax to make it non-clustered.

    Or if you already have a clustered index defined on the table when you define a PK. The PK will be nonclustered if there is already a clustered index on a table.