Posted: 27 Aug 2018 22:38 EDT Last activity: 28 Nov 2018 15:18 EST
pyGUID vs Compound Key
Let's say, we have three compound key candidates in MyCo-Data-Customer class. I can specify Key1, Key2, and Key3 in class form as compound keys but also Pega recently started to provide "pyGUID" which is automatically generated by Pega with random number (I guess this comes from system time?). What are pros and cons using these?
I would say that it comes down to what you care about in your key. If you can build a compound key that will provide you an appropriate level of uniqueness, but is meaningful to your developers, that may be a way to go. If you can't, or you don't care about it being meaningful, letting the system generate is unique key on your behalf means you don't need to worry about how the key is constructed and what may happen in the future to the properties you would otherwise have used in a traditional compound key.
pyGUID is also good if you need to create some record before you fill out other data on the page. Once I used this approach because the property which could be potentially used as a key wasn’t available in the begginning but I was forced to create some references to this object during create process.
pyGUID is also good if you don’t care about value of the key.
I think, in general we could apply the rules and best practices from relational DBs