cancel
Showing results for 
Search instead for 
Did you mean: 

Is it always mandatory to have unique attribute while defining new data model?

Former Member
0 Kudos

Hi Colleagues,

is it always mandatory best practice to provide some unique identifiers for types while defining new types or extending existing types? Please advise like what is the recommended approach here? Thanks, Vipin

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

It is not mandatory to have unique attributes of course, PK is only required unique attribute.

Best practice is that 99% of the time you want to have a unique attribute(s).

If the type if a Catalog aware type if must have a unique key for the synchronization, the unique attributes in items.xml need to match the unique key for synchronization otherwise it will give us problems.

For non catalog types we have to question when we want to take the risk of having duplicate entries entered by the business users or by back end processes. Without a unique attribute(s) we won't be able to validate the items against the existing records.

We don't need to create an arbitrary unique attribute for types (e.g. code/uid). We can also use a compound key made up of existing attributes (also relation attributes) on the type.

Lastly, we shouldn't rely on the persistence layer to maintain database integrity for uniqueness. In a highly concurrent system with multiple threads hitting the database at the same time it is still possible to create duplicate entries. We should have a unique database index backing the unique attributes.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Vipin,

There's no simple answer to your question. In every project you can find some items that don't need unique attributes at all. Personally, I would always try to answer following questions first:

  1. Are there any existing attributes (= coming from business requirements or technical design directly) that could be considered as unique ? If so then I would definitely go with appropriate configuration on the items XML level, especially taking care about DB level unique constraints (achievable by index element).

  2. Another case is when in theory you don't need such unique attributes but having them would help you in certain cases. Typical example is about project data that usually contains many INSERT_UPDATE statements and even single unique attribute (of course not PK, as this is out of our control) - e.g. code helps to avoid unnecessary duplicates in case when a certain IMPEX file is executed several times.

That would be it ... in a nutshell 🙂

Mirek