Standard Asset : Why is the field 'ID' the primary key and the type guid?
I was wondering why the Standard asset primary key is a GUID and not a STRING? It seems like a departure from the other classes.
I am not asking for a change, just found this interesting as I am inheriting from this class to create another class type.
Best Answer
-
Nicholas_Velich Cireson Consultant Ninja IT Monkey ✭✭✭✭Hi Christopher,
We would have to go back to the product's original development to know exactly how/why some back-end components were designed. That being said, we can do a decent job of guessing. I see three groupings here:- Hardware Asset - This one is a bit unique because you can configure the Primary Key as an option in Settings. You could select Asset Tag, Serial Number, Principal Name, Id, or SID here. This one needs to be a String because of the variety of types of fields it could store. Regardless what you pick here, the HW Asset still has an independent object GUID for representation within SCSM.
- Locations, Organizations, or anything else with a String as the PK. - Display Name is typically used because it is a user-facing field, and is typically how someone would refer to these objects. For these objects, there is some reason why the key should not change or be duplicated. Perhaps the objects are tied to a workflow, or perhaps it just doesn't make sense to have a duplicate given a particular key (for example, it wouldn't make sense to have two locations with the exact same name).
- Everything else - Taking Standards as the talking point here, they are fairly open-ended and organizations implement them quite differently. It might be viable to have two Standards with the same Name (perhaps further differentiated via Type or some other value). Although the "Name" field could feasibly have been locked in as a Primary Key during design to keep it consistent, it is ultimately more flexible to only use the GUID behind the scenes.
One thing to remember is that each of these classes ultimately becomes an object in SCSM, and each of those objects does have a unique GUID used within SCSM. All Primary Keys in the CAM classes are just additional restrictions based on business logic/requirements.
As the product has grown and been applied in different ways, perhaps different key types would be better in some cases; however, the tricky part about primary keys is: once you set them, you can't easily change them!
Hope that clears some of this up for you.
Thanks,
Nick5
Answers
We would have to go back to the product's original development to know exactly how/why some back-end components were designed. That being said, we can do a decent job of guessing. I see three groupings here:
One thing to remember is that each of these classes ultimately becomes an object in SCSM, and each of those objects does have a unique GUID used within SCSM. All Primary Keys in the CAM classes are just additional restrictions based on business logic/requirements.
As the product has grown and been applied in different ways, perhaps different key types would be better in some cases; however, the tricky part about primary keys is: once you set them, you can't easily change them!
Hope that clears some of this up for you.
Thanks,
Nick