Use of an autonumbered ID

Use of an autonumbered ID

  
What is the advantage of using an autonumbered id as the key in a database table vs using an integer value that is known to be unique as the key?  For example, let's say that a client has a list of customers, all unique, and all with a unique integer customer_id.  Obviously this could be stored in a customer_number column in the table, but what would the drawbacks be to simply pushing this into the id column when creating a new record?  Assume also that the data is being inserted into the customer table from a process outside of the applicaiton.

Chuck 
Chuck -

There's no technical advantage. My concern with this scenario, is that I have had way too many folks promise me on their good name that the Id number they gave me 1) is actually unique and 2) will NEVER change... only to have that promise get broken. It's happened to me so many times, I simply refuse to believe it and insist on using my own autogenerated ID, and then putting an index on their ID column for quick lookups. :D

J.Ja
Hi Justin,

Thanks for that info.  My initial thought was that it was discouraged in order to work well with the logic behind the native CreateOrUpdate actions associated with each entity, but I can also see the concerns over it changing or being a duplicate.  In this scenario, on this one table, we can be quite sure that neither will happen, though I will need to put them on the spot once again to get that assurance. This particular ID happens to be used acrossso many transactional child tables that having the key ID be the same as the client’s assigned id would make direct sql access to the data and debugging much easier, especially if the data were exposed as read-only on another system where the operators aren't as familiar with proper joins as they should be. 

Chuck
Chuck -

You can make the OutSystems ID column NOT autonumber if you would like, incidentally. It will work fine. The way Create works, it ignores the ID you specified if Autonumber is true for the ID. CreateOrUpdate runs a SELECT first to see if it should UPDATE, and if nothing is found, reverts to the Create behavior.

J.Ja