We already have a UUID column for few tables such as AM_API and AM_APPLICATION which is used to uniquely identify a record. The reason why we have a UUID column is because it is the unique identifier that we expose to the end user. Having a UUID for this purpose means that end users cannot guess the possible unique identity of other entities, which is possible if we exposed an integer based identifier.
However at table level we were still maintaining an auto incrementing primary key. So the UUID was used externally but the integer key was used privately to maintain foreign key relationships within the schema. We first thought it might be a good idea to dispense of the auto incrementing primary key and use the UUID as the primary key itself since it seemed like we had two columns that served somewhat duplicate purposes. But I have been doing some research regarding this and have found that the industry is divided a bit regarding this point. These links advocate UUIDs as primary keys https://blog.codinghorror.com/primary-keys-ids-versus-guids/ https://www.clever-cloud.com/blog/engineering/2015/05/20/why-auto-increment-is-a-terrible-idea/ These links recommend auto incrementing integers as primary keys http://stackoverflow.com/questions/404040/how-do-you-like-your-primary-keys/404057#404057 http://stackoverflow.com/questions/829284/guid-vs-int-identity We can still continue with our hybrid approach of having both an auto incriminating integer as primary key and using the UUID for external interactions, whihc seems to be also used by some to get the best of both worlds. So how should we proceed? -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
