GUIDs GUIDs everywhere, but how is my data unique?

  • Keith Hays

    Say Hey Kid

    Points: 707

    yeah, I am currently checking to see if azure has the equivalent of a P 50 (their nomenclature) P20 + P30 storage system per database system. If they do it will be pretty awesome, all other things being equal.

  • Keith Hays

    Say Hey Kid

    Points: 707

    I would note though, you do have to be careful of the calculators when translating from say 100,000 iops to their monthly "Storage Transactions" 100,000 iops is 260 Billion monthly storage transactions.

  • Keith Hays

    Say Hey Kid

    Points: 707

    Btw, I look like I have gone way off topic, but anyone looking to move to the cloud should look at some of the restrictions for full cloud based SQL Servers specifically around guids.

  • gene-683843

    Grasshopper

    Points: 24

    I have always held the opinion that the use of an artificial PK for database table design (GUID or otherwise) is a lazy way to maintain uniqueness of data. If the table is designed correctly, there will be an actual PK using one or more field attributes. If you can't identify the actual PK the entity was not correctly designed. If there is integration involved with other data sources, the ETL tool should have the logic to merge the data into a single row with business logic to determine conflict resolution for the remainder of the fields that are not part of the PK.

    Best Regards,

    Gene Underwood

  • x

    SSC-Insane

    Points: 23593

    gene-683843 (12/18/2014)


    I have always held the opinion that the use of an artificial PK for database table design (GUID or otherwise) is a lazy way to maintain uniqueness of data. If the table is designed correctly, there will be an actual PK using one or more field attributes. If you can't identify the actual PK the entity was not correctly designed. If there is integration involved with other data sources, the ETL tool should have the logic to merge the data into a single row with business logic to determine conflict resolution for the remainder of the fields that are not part of the PK.

    Best Regards,

    Gene Underwood

    This debate never ends, and always one side or the other declares the opposite side to be "lazy", unintelligent, or otherwise lacking the skill to identify a natural key or understand the benefits of surrogate keys or whatever. Too bad we couldn't come up with a catchy phrase for this useless debate like "key-krapshoot" or something.

  • Bill Talada

    SSChampion

    Points: 11956

    As a development DBA who designs for projects exclusively using one philosophy or the other, I can say that GUID PKs are vastly superior to the non-ANSI Identity PKs in speed and code versatility (freedom). I could easily write an article with the opposite polarity of distortion of the author and "convince" people GUIDS are better. I support both philosophies...but not a mixed approach; it depends on the team and project leader really.

    Saying one is right and the other is wrong is just ignorant trolling.

  • tromeo

    SSC Veteran

    Points: 289

    Apologies, for the miscommunication. NOT lazy DBA’s, lazy developers. Not all developers are lazy, just many that I’ve met. It is not personal.

    Tom Romeo
    Practical Compliance Solutions Corp.
    One Orient Way - Suite F156.
    Rutherford, NJ 07070-2524
    --------------------------------
    www.complianceabc.com
    email: tromeo@complianceabc.com
    Phone: 201-728-8809

  • don.schaeffer

    Ten Centuries

    Points: 1165

    The statement is made " The GUID should be generated at the data tier or in the database itself." without support. Of course this is one reason developers love guids; their code can generate a guid that can be used for both a top level and child records without having to insert the parent record, query to get the identity value, and then insert the child records.

    As a DBA I dislike guids but I would like to hear a reason for why the guid should not be generated by application code.

  • gene-683843

    Grasshopper

    Points: 24

    Gentleman,

    In regards to both your responses to my post.

    1) I am certainly not an "ignorant troll" and simply gave my opinion. I have been involved in database design for 20 years and do not appreciate the personal attack. I taught a professional development class in 1997 - 1999 that included database design and implementation long before the use of GUIDs as PKs were available. So I may be "old school" but there is certainly still relevent course material for relational database design that supports my opinion.

    2) "a lazy way to maintain uniqueness of data" does not infer that an opposing viewpoint "declares the opposite side to be "lazy", unintelligent, or otherwise lacking the skill". If it was taken that way, it certainly was not my intention and I apologize if you indeed took it this way.

    I have been a non-contributing member here for several years. This conversation has definitley pursuaded me to remain a non-contibuting member in the future.

    Best regards,

    Gene Underwood

  • John Mitchell-245523

    SSC Guru

    Points: 148771

    Gene

    Please reconsider. You're unfortunate enough that your first contribution happened to be to a debate that invariably inspires passionate partisanship. In such exchanges, comments are made that can be taken as personal attacks, without being meant in that way. I for one would be interested to hear your views on other subjects in due course of time.

    John

  • tromeo

    SSC Veteran

    Points: 289

    In multi-tier applications where you don’t necessarily know how the client will connect, ie browser from a computer, wi-fi, cellular, iPhone app,… and the application may be hosted or in the cloud, if the transactions are not tightly coupled and something happens on the network layer, it is possible to have inconsistent results. For example, I’m currently on a project that throws a lot of foreign key exceptions, and yes the foreign keys are GUIDs. There should never be a foreign key exception, ever. Again, perhaps your application is bulletproof, but I’ve seen many applications fall apart due to bad design.

    Tom Romeo
    Practical Compliance Solutions Corp.
    One Orient Way - Suite F156.
    Rutherford, NJ 07070-2524
    --------------------------------
    www.complianceabc.com
    email: tromeo@complianceabc.com
    Phone: 201-728-8809

  • tromeo

    SSC Veteran

    Points: 289

    me too.

    Tom Romeo
    Practical Compliance Solutions Corp.
    One Orient Way - Suite F156.
    Rutherford, NJ 07070-2524
    --------------------------------
    www.complianceabc.com
    email: tromeo@complianceabc.com
    Phone: 201-728-8809

  • robert.diley

    SSC Eights!

    Points: 860

    Philip.Daniels1971 (12/18/2014)


    The fragmentation problem was worked around years ago with the invention of Combs, long before NewSequentialId existed. It allows sequential Guids to be created on multiple clients without hitting the database. Very handy for saving complex object graphs. I have had a piece of C# to do this for at least 6 years...I believe NHibernate has a similar feature though I haven't used it.

    This article is really just an argument against surrogate keys. Having used both natural key designs and surrogate key designs, I gotta tell you, surrogates every time 😀

    I don't believe that the article is at all an argument against surrogate keys: Although the author does appear to have a preference for natural keys, the status code example used to advance the argument actually uses surrogate keys, just not GUIDs.

  • halifaxdal

    SSCoach

    Points: 19741

    While the Server and ConnectionData fields may seem redundant, the ConnectionData field may contain and IPV4 or IPV6 address

    shouldn't it read: While the Server and ConnectionData fields may seem redundant, the ConnectionData field may contain an (not and) IPV4 or IPV6 address?

    BTW: I like your article and I am totally on your side of avoiding GUID

  • tromeo

    SSC Veteran

    Points: 289

    shouldn't it read: While the Server and ConnectionData fields may seem redundant, the ConnectionData field may contain an (not and) IPV4 or IPV6 address?

    BTW: I like your article and I am totally on your side of avoiding GUID

    Yes you are correct -

    Tom Romeo
    Practical Compliance Solutions Corp.
    One Orient Way - Suite F156.
    Rutherford, NJ 07070-2524
    --------------------------------
    www.complianceabc.com
    email: tromeo@complianceabc.com
    Phone: 201-728-8809

Viewing 15 posts - 16 through 30 (of 38 total)

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