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

In message <LvGdnZoLb_yebPjeRVnyjA_at_pipex.net>, Roy Hann <specially_at_processed.almost.meat> writes
>"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?

An EAV system probably wouldn't need to use many tables, because it holds each attribute in a separate row.

>
>> 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.

It only takes seconds to create a table, once you know what the table structure is going to be. In systems where the data structure is unknown at design-time you would need to give the users the capacity to add or modify tables. That isn't going to be any better than using EAV.

>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.

In the early stages of agile development you probably have only a vague idea of what entities and attributes are going to be required in the final system. By building a system where the users can add entities and attributes without involving the developer you allow the users to define what the final system needs. After collecting the metadata you have the information required for the data modeller to put together a properly structured relational data model.

-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.