December 18, 2014 at 5:11 am
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.
December 18, 2014 at 5:21 am
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.
December 18, 2014 at 5:23 am
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.
December 18, 2014 at 5:23 am
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
December 18, 2014 at 6:55 am
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.
December 18, 2014 at 7:12 am
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.
December 18, 2014 at 7:46 am
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
December 18, 2014 at 7:46 am
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.
December 18, 2014 at 7:53 am
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
December 18, 2014 at 8:01 am
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
December 18, 2014 at 8:03 am
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
December 18, 2014 at 8:05 am
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
December 18, 2014 at 8:44 am
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.
December 18, 2014 at 9:20 am
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
December 18, 2014 at 10:16 am
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 37 total)
You must be logged in to reply to this topic. Login to reply