Difference between revisions of "Features/Duplicate prevention"

From TempusServa wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:


Example:
Example:
   If you are adding a record to an entity, it would be annoying to later find out that the record already exists. Now you have two records with the same data, but with different DataIDs. To prevent this there should be some part of the data in the record that is impossible to exist in another record. An example of this would be the social security number of a person. If you are adding a record of a person whose SSN already exists in the system, then the person is certainly a duplicate.
   A hr-management system is used to hire new employees that have to be registered with information such as name and email address. During this registration mistakes can happen where an employee is registered multiple times, creating duplicates in the system with different system ID's. To prevent this there should be some part of the data from the employee that would not impossibly exist for another employee, such as the email address which by design are unique. If you are adding a record of an employee whose email address already exists in the system, then that employee certainly already exists in the system. Other suitable types of data could be Social Security Numbers or CPR numbers, which are also unique by design. If no such suitable data field is available, two or more fields can be used, so that they in combination constitute a unique value. It is for example unlikely that two people with the same name and same date of employment should exist.


== How to do ==
== Guide ==
To prevent duplications when records are created, the entity needs to be set up right. Either a single field or a combination of fields need to be designated as being a unique key, meaning that if you attempt to create another record with the same combination of fields, you will be prevented form doing so. This can be some field with inherently unique data or for example the combination of a date and a name, where the chance of another record sharing the same date and name is considered extremely unlikely.
To prevent duplications when records are created, the entity needs to be set up right. Either a single field or a combination of fields need to be designated as being a unique key, meaning that if you attempt to create another record with the same combination of fields, you will be prevented form doing so. This can be some field with inherently unique data or for example the combination of a date and a name, where the chance of another record sharing the same date and name is considered extremely unlikely.



Latest revision as of 13:25, 28 August 2023

What it is

Example:

 A hr-management system is used to hire new employees that have to be registered with information such as name and email address. During this registration mistakes can happen where an employee is registered multiple times, creating duplicates in the system with different system ID's. To prevent this there should be some part of the data from the employee that would not impossibly exist for another employee, such as the email address which by design are unique. If you are adding a record of an employee whose email address already exists in the system, then that employee certainly already exists in the system. Other suitable types of data could be Social Security Numbers or CPR numbers, which are also unique by design. If no such suitable data field is available, two or more fields can be used, so that they in combination constitute a unique value. It is for example unlikely that two people with the same name and same date of employment should exist.

Guide

To prevent duplications when records are created, the entity needs to be set up right. Either a single field or a combination of fields need to be designated as being a unique key, meaning that if you attempt to create another record with the same combination of fields, you will be prevented form doing so. This can be some field with inherently unique data or for example the combination of a date and a name, where the chance of another record sharing the same date and name is considered extremely unlikely.

Picture 1

To set a field of an entity to be a unique key, go to that entity in the back-end and select your chosen field as shown in picture 1.

Picture 2

The unique key feature is an advanced one, which means that you have to toggle the advanced view as shown in picture 2.

Picture 3

Now enable the check mark as shown in picture 3. Your chosen field is now part of a unique key. If this is the only field with this check mark enabled, then this will be the only key. If you select a second or third field, then the combination of the values of those fields will be the unique key.