4

As far as I know, SAP CRM and HANA both utilise GUIDs to uniquely identify records instead of using classic incremented integers. Are there best practices or clear guidelines that cover their use?

Here are some factors I've considered in favour of GUIDs:

  • Offline creation of objects. IIRC GUIDs are near-guaranteed to be unique in these situations so merging or integration of disparate data sets is not an issue.
  • Surrogate keys have distinct development advantages. While incrementing integers are a form of surrogate key, use of different number sequences can impose a functional meaning on them.

And some scenarious that favour classic keys:

  • Users require human-readable keys to identify records in the system. This can be handled in GUID tables by also specifying an external ID with a readable value.
  • Users want to use number sequences to identify different types of records, similar to sales or purchase documents. Though I actually consider this bad design.

What scenarios for custom development would make you prefer GUIDs over classic keys?

Is blanket-usage of GUIDs for all tables a good idea?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Lilienthal
  • 4,327
  • 13
  • 52
  • 88

1 Answers1

6

To answer the question at the end: No, it isn’t (at least not in an ABAP environment, and I doubt it’s sensible elsewhere). Using GUIDs for primary keys everywhere makes it awfully hard to maintain and follow complex foreign key relationships at runtime. Just imagine having to debug a program that handles everything using GUIDs instead of the semantic keys you’re used to. And remember that the total length of the primary key may not exceed 255, and the total length of the primary key should not exceed 120 if you want to be able to transport table entries using fully qualified keys. Using GUIDs in composite keys blows the keys up unnecessarily, and using them as synthetics keys makes using foreign key relationships virtually impossible. So no, using GUIDs everywhere is not a good idea, especially not for configuration / customizing data.

It is however a good idea to use GUIDs in almost every place where you would have used a number range object in “old-school ABAP development”. GUIDs can be generated by the application server, while number ranges require network communication to the enqueuing server. (Yes, there is some buffering involved, but generally speaking, GUIDs are a lot faster and easier to handle). So unless you need your keys to follow a certain pattern, you should consider using a GUID. Even if you need some kind of sequential number for whatever business reasons, it might be sensible to use a GUID as the primary key and store the sequential number inside an (indexed) attribute to increase flexibility at development time.

vwegert
  • 18,371
  • 3
  • 37
  • 55