Re: Modelling objects with variable number of properties in an RDBMS

"Bernard Peek" <bap_at_shrdlu.com> wrote in message news:4tHfgQLCbeZDFw7N_at_shrdlu.com...
> In message <3fqdnUHV_-Qf__jeRVnyjQ_at_pipex.net>, Roy Hann
> <specially_at_processed.almost.meat> writes
> >"Bernard Peek" <bap_at_shrdlu.com> wrote in message
> >news:9Dc+bybsWUZDFw5n_at_shrdlu.com...
> >
> >> That's one reason why people keep trying to use it. The second one,
> >> unfortunately, is that sometimes it's the only alternative. Sometimes
> >> you just don't know the whole data structure at design-time.
> >
> >One day, ours will be a real profession, and we'll be allowed to say
"sorry,
> >you can't do that" without getting fired. In fact we'll have a legal
duty
> >to say it, just like engineers and accountants and proper professionals.
>
> But that's not the problem. The problem is that it is possible to build
> a database using the EAV system, but it will require constant
> maintenance and skilled users to keep it working.

No that's not the problem. The problem is that it is trivially easy to create new tables in an RDBMS--literally in a matter of tens of seconds--but most people seem to think it is both possible and necessary to improve on "trivially easy".

Why would we want to even if we could? What would be the point?

> That's why it has to
> be a fall back option, only used when there are no other alternatives.

It isn't a fall back option. It accomplishes exactly nothing. I don't even see how it can create the illusion that it does anything. If it even looked like it worked I'd be more sympathetic.

> I wonder whether there's a role for EAV systems in prototyping systems
> using agile development?

No, no, no! A thousand times no! What could be more agile than creating a real table? It takes literally seconds.

Doing nothing is not being agile. Doing nothing is doing nothing. And by doing nothing while still pretending there is something to be done you are shifting the burden onto someone else, namely the programmer. What makes programmers better able to understand what database designers cannot? What makes their tedious low-level procedural languages better tools for capturing their understanding?

> An EAV database could be used to collect
> metadata during the early development stages, and that metadata could
> then be used to build the final database system, replacing the temporary
> EAV model.

Please elaborate on this, because I can't make head nor tail of it.

Roy Received on Mon Oct 31 2005 - 11:24:01 CET