On Sat, 2 Feb 2008 09:45:57 -0800
David Fetter <david@fetter.org> wrote:
> On Sat, Feb 02, 2008 at 01:38:19PM +0100, Thomas Pundt wrote:
> > Hi,
> >
> > vladimir konrad wrote:
> >> I think that I understand basic relational theory but
>
> Clearly, you'll have to revisit that thought.
>
> > [example stripped]
> >
> > Yes, this is known as eg. Entity-Attribute-Value model (cf.
> > wikipedia).
> >
> > IMO most times its disadvantages (it can be very hard to write
> > performant queries compared to the traditional row based model)
>
> Make that, "impossible." The "flexibility" stems from fear of
> making a design decision.
> The second and smaller price is having the system bog down entirely
> and have to be scrapped, whether it's 3 months down the line, or 3
> years.
>
> The math beneath this is that query complexity goes up like
> O(E!A!V!) for Entity, Attribute and Value.
> The first price, though, and by far the biggest, is that it's
> impossible to maintain any kind of data integrity in such a system,
> as such constraints, by their nature, are application-dependent.
> Two applications means you're violating the SPOT (Single Point of
> Truth) Rule, and that in turn means your data turns quickly into
> incomprehensible gibberish.
>
> > weigh higher than you gain (in flexibility) in relational
> > databases. But it sure has its uses cases.
>
> Why, yes. I encourage all my competitors to use it. ;)
There should be some standard refactoring technique *and* tool to
move from EAV model to something saner on the long run.
Say you still don't know what the users will need and you want to
give them a chance to experiment with which proprieties they find
themselves more comfortable with (build up a better model) and you
don't want to give users access to ddl, or suppose this part is not a
critical part of the application and you want to let the users
customise it without access to the ddl...
I didn't take the time to really think how you could stay far from
major pain when you start from EAV model and you want to normalise
stuff...
I'd go for a naive/brute force approach.
As usual I'd try to encapsulate this kind of stuff and centralise the
"access points" and then once I've to refactor this I'd just use grep
for some kind of signature and fix it case by case.
But well... if I knew in advance there is a standard technique
(tool?) to build up EAV models in a way they can be "easily"
refactored, I'd be happier ;)
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
