Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
A surrogate key is nothing but an artificially created PK meaning, you should have a column or group of columns in the affected table already giving you the uniqueness you are looking for.
If you cannot find an unique identifier -column or group of columns- in the affected table I would say that there is a serious issue with your design.
Surrogate Keys are meaningless from the business perspective.
Surrogate Keys are allocating additional space in your table.
Surrogate Keys require you to create a specific process to populate them e.g.: we are adding a level of complexity.
Why would you want to face all these issues when you can easily build a PK using the actual information already sitting in your affected table?
That being said... they are here to stay. Sad, isn't it? : )
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
That being said... they are here to stay. Sad, isn't it? : )
Not really, if you have a natural key that is prone to change, then using a surrogate key will prevent you from having to cascade the update of that key. But sequences can certainly add overhead to large transactions.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Bookmarks