I'm sure we can agree that composite keys are a major handicap in dealing with ORM tools. The Hibernate business team is absolutely wrong, by the way -- it's not that the data model is broken, it's that Hibernate is broken and cannot deal with a perfectly reasonable data model.
The question is why does a "good" ORM require a "bad" data model? The ORM tools should be mature enough to handle good database design.
Sure, I've put surrogate keys on databases that have 5 columns as a composite primary key, because good database design in that case leads to an unacceptably slow application. However, your #2 "The primary key must be a surrogate key with no business value," makes me want to run screaming, given that the primary key is SUPPOSED to have business value.
As well, I was led to believe that a unique number wouldn't work, it *had* to be auto-increment. Our primary key is 2 numbers, which should be simple to concatenate together, either making a decimal by having a decimal point as a separator, or just smushing them together with appropriate leading 0's, as there are upper bounds on both numbers.
I would be fine with a surrogate key that actually means something. On principle, I find that a system that requires what amounts to "row numbers' seems broken to me.
I'm sure we can agree that
I'm sure we can agree that composite keys are a major handicap in dealing with ORM tools. The Hibernate business team is absolutely wrong, by the way -- it's not that the data model is broken, it's that Hibernate is broken and cannot deal with a perfectly reasonable data model.
The question is why does a "good" ORM require a "bad" data model? The ORM tools should be mature enough to handle good database design.
Sure, I've put surrogate keys on databases that have 5 columns as a composite primary key, because good database design in that case leads to an unacceptably slow application. However, your #2 "The primary key must be a surrogate key with no business value," makes me want to run screaming, given that the primary key is SUPPOSED to have business value.
As well, I was led to believe that a unique number wouldn't work, it *had* to be auto-increment. Our primary key is 2 numbers, which should be simple to concatenate together, either making a decimal by having a decimal point as a separator, or just smushing them together with appropriate leading 0's, as there are upper bounds on both numbers.
I would be fine with a surrogate key that actually means something. On principle, I find that a system that requires what amounts to "row numbers' seems broken to me.