On Monday, September 23, 2013 4:14:44 PM UTC-4, Lukas Eder wrote: > > > 1. jOOQ assumes working on a normalised schema. Changing primary key > values is usually not expected practice. > 2. If the primary needs to be changed, then this is mostly due to > scripting / batching behaviour, where regular SQL is better suited than > CRUD. >
I disagree. There is a school of thought that it is highly desirable to use natural keys whenever possible and avoid unnecessarily creating surrogate keys. When using a natural key you are almost inevitably more exposed to them changing, as anything that is meaningful to the user or which originates in the world instead of being under your control, opens up this possibility. With update cascade this is really not such a big deal. And I don't think normalization has anything to do with this. Not everyone agrees with this philosophy, as the pro / con surogate key debate is an old and endless one, but it is not really so uncommon. To be simply unable to perform such an update is a *huge* deficiency. I don't really want to open up that debate here, but there ARE distinct advantages of not generating a surrogate key when you have a good natural candidate key already, even if they can change. I also will need this feature. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
