-Field length is being extended but as the field is being used in secondary key this cannot be done.
-The secondary key was not optimal an needs to be changed.
-The secondary key is no longer needed and it needs to be dropped.
In order to improve performance it does not make sense to continually add further secondary keys on the end of the key list as this impacts the performance in very negative way.
Please allow change at least for secondary keys without marking such a change as a breaking one.
Adding new keys already triggers indexing. So dropping the current index and creating a new one does not sound as a problem from my point of view.
Comments
Hi,
Thank you for the clarification.
I am mainly interested in point 2)
Adding the new clustered index also incurs the index rebuild. So honestly I do not see the (huge) difference between adding the new key because of this constrain and changing the current one as both actions will incur the rebuild of an index. So building an index in a production is indeed possible. I however see the downside when new keys are being added to the existing ones as at some point table can be overwhelmed with indexes that are no longer in use.
Best Regards,
Miljan Milosavljevic
Category: Development
Thank you for your feedback. We are not considering the suggestion at this time due to the following reason:
The only key changes that you cannot do are
1) Change primary keys
2) Change clustering keys
3) Add new unique keys to existing tables (as that will most likely fail with a real table).
We could relax the last two, but changing clustering key while not destructive, requires rebuilding the table which we would like to avoid in production. Adding a new unique key is just going to be annoying if a partner ends up locking themselves out of their extension by creating a change that cannot be synced.
Sincerely,
Kennie Nybo Pontoppidan
PM, Microsoft
Category: Development