Currently when metadata about the key of a database object is missing we apply an heuristic to infer a synthetic key. This mechanism usually comes up with something that doesn't match user expectations and/or doesn't align with the actual data and or schema present in the database. We have had a lot of feedback over time about several problems that the current mechanism has:
1. Users find it very hard to understand what just happened
2. We reason about nullability but we fail to consider other aspects that may make a column unsuitable as a key, such as order comparability, e.g. spatial types shouldn't be ever part of a key
3. We have had reports that the behavior can effectively be random, e.g. going through the process may result in different outcomes each time
4. As with many other things, once you have carefully picked the right set of columns for the key, updating the model from the database will overwrite your choice, which can be very annoying.
I don't have a specific idea on how to improve this other than stop doing key inference altogether and instead allow an invalid model to be generated and useful warnings to be shown.
1. Users find it very hard to understand what just happened
2. We reason about nullability but we fail to consider other aspects that may make a column unsuitable as a key, such as order comparability, e.g. spatial types shouldn't be ever part of a key
3. We have had reports that the behavior can effectively be random, e.g. going through the process may result in different outcomes each time
4. As with many other things, once you have carefully picked the right set of columns for the key, updating the model from the database will overwrite your choice, which can be very annoying.
I don't have a specific idea on how to improve this other than stop doing key inference altogether and instead allow an invalid model to be generated and useful warnings to be shown.