Primary Keys

Composite primary keys

Even though it is possible to define a composite primary key, this should be avoided to ease data management in the Jobs. If the primary key is a composition of many elements, use a surrogate key instead.

Types

For technical and presentation reasons, AUTO_INCREMENT can be prefered to UUID type. Indeed, bulk loader does not handle UUID for instance, and UUID are not nice to see in the Web UI.

Non-MDM controlled primary keys

Be really careful with non-MDM controlled primary keys. Using non-MDM controlled primary keys should be reserved for very static entities, when you are 100% sure the primary key value will never change.

This can ease the update of the entity by having not to look up the primary key value, as you already know it.

Naming conventions

Primary keys should be named using the following convention: Id + entity name (e.g. IdPerson). This will ease the element name retrieval in the Integration perspective, enabling the developer to guess it, and not to check constantly the data model.