The risk of this is that you make yourself dependent on the quality of createguid of the platform, and creategui depends on the state of the machine rather than the DB, (which could be a problem when you work with e.g. VMs, and is not very nice as design principle).

signed 32-bit sequences roll over with 2 billion, iow not anyday soon, and you are not dependent on which system your client runs, and if it might be a copy of a VM that was used to put records in the db before. Maybe use 64-bit ints for fastmoving tables.

In my old programs I used for Id ... drum roll ...GUID. Yes, yes, the same. Just VARCHAR in the table.Generation of GUID was done in code (CreateGuid procedure), and a string was written to the database.

Do you think this approach is safer?In addition, there is absolutely no chance that within one GUID database will be repeated, which can lead to a data read error.

Safer? No. Less Safe? No. Different kind of information. For example a GUID borows info from the network adapter, motherboard, current date and time of the users locale and more, to create a hard to replicate unique ID. it is a bit long though for the purpose. Any 64bit can be convert to 1 byte for the country.1 byte for the brunch in that country1 byte for user of that brunch.1 byte for the year 4 bytes for the auto increment and you have created your own GUID in far less space. I doubt you will find any table that has more than 4 billion entries per year from a single user. That includes bot users too (bot user is the user used to automatically import data in to your application, financial statements etc) well stock exchange data might hit that boundary but you just add a new user for each day of the week and boom problem solved.As for the no chance well there is "virtually no chance", its not the same as no chance. The thing is why would want to limit your self to string comparison for your indices, which is slower than an integer comparison, and use twice the space, for an ID that has no reason to be unique outside your application?

Logged

Good judgement is the result of experience … Experience is the result of bad judgement.