Yet Another DBA (3/26/2015)
If the database fits in memory and the load is adequate, where locks and page splitting is not an issue, then GUIDs is not necessarily a practical problem, just a theological one.If the GUIDs make life for the developer easier and less bug prone then good, as long as the performance is good enough with some leeway for the future why should the dba worry that much. An extra minute added to the backups and the cost of another 30GB of ram can be cheap, especially when compared to time needed for fixing bugs and the loss of face with the clients/business.
Not everyone has massive databases, not everyone has excessive loads, not every one is Google. There is a lot of snobbery about only using techniques that will scale to millions of users doing gazillion of hits every second. I wouldn't rate the GUID argument in the top set of issues for design, development or administration.
Design for the real world is more important that delusions of grandeur.
As a DBA, I agree with you, to a point.
GUIDs are not inherently evil. We know very well what issues they cause. They lead to more fragmentation. That's an issue if you have lots of scans, but not an issue if you have lots of point look ups. They make index keys wider, taking up more space on disk in both the key where they're used and the nonclustered indexes if the GUID is a cluster. And all these problems can be worked around to a degree if they actually cause impact.
But...
I fall down when I hear the "we're not building Google" argument. It's an excuse to simply ignore known issues rather than address whether or not those issues are applicable in a given situation. I've worked on systems (small systems) that successfully implemented GUIDs with no issues at all. I've also worked on systems (small systems) that the GUIDs caused massive impact. And the systems where they hurt were not Google-level systems.
GUIDs are not evil. But they are also not benign. I don't think it's even remotely unreasonable for a DBA, when presented with the proposal for a design using GUIDs, to look at it with a degree of suspicion. Evaluate the impact, test the design, ensure that, in this case, it's OK. And if it's not, propose alternatives. In short, excercise the knowledge and judgement that, at least in theory, you're paying that person for.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning