J
Jamie Collins
Jeff said:
The tone is Celko's, not mine I hope <g>.
What *I* have tried to say is that EAV has its place, albeit in a
limited number of applications which are well documented.
Personally, I find the attribute-centric approach more interesting. If
you've read more than a couple of my posts you'll know I'm particularly
keen on writing as many database constraints as I possibly can to
maintain data integrity. I am very wary of the reliance on front end
applications or even business rules engines to maintain data integrity.
I've worked on a clinical DBMS, being a hospital prescribing
application, and I can tell you that EAV has no place in electronic
prescribing, something described as a 'life critical' system (I had to
have multimillion dollar insurance against someone suing me _in my own
right_). Oh yes, we had our constraints close to the data and in the
database. I saw someone's sig line yesterday: "A front-end is something
that tries to violate a back-end"; I couldn't have put it better myself
(apologies if that quote sounds smutty <g>)
New drugs are being made available all the time, so that part of the
database plus the data updates was purchased from a trusted source. Our
application used industry standard keys throughout, all maintained by
trusted sources (e.g. the British National Formulary). There was one
artificial key in the whole app and that was merely a staging table
while duplicates in externally generated episode IDs were resolved.
I trust you understand why you will not get the pros of EAV out of me:
I'm a database constraints evangelist
I've also tried to convey that I don't see EAV as 'just wrong' and I'm
happy to repeat that message. It's just I usually see EAV used where an
attribute-centric approach would appear to me to be more appropriate.
To employ the usual analogy, sometimes a hammer is the correct tool but
often one is misused to bash in screws, often by people who are
"Unskilled and Unaware of It" (google it) which makes them potentially
dangerous.
There's a guy sitting right behind me (I'll just reduce the zoom in my
word processor so he can't read over my shoulder <g>), sole developer
on an in-house app. The product manager got suspicious when seemingly
fundamental amendments to the schema were implemented very quickly.
When he took a look at the database he found - you've guessed it - one
table, two stored procs (a Get and a Set), no business/enterprise keys
(GUID INDENTITY PK), no constraints, etc. The developer is from an OOP
background and these guys tend to view the database as a dumb store for
their business rules engines and so EAV makes perfect sense. The
product manager was not best pleased, though, because he was planning a
second app to be based on the same database but immediately realised
that he had no schema and all the business rules (defaults, domain
values, etc) were locked in ASP.NET code.
Jamie.
--