Re: EAV (Re: Object-relational impedence)
Date: Tue, 25 Mar 2008 10:56:04 -0700 (PDT)
Message-ID: <a39a2bfd-de5a-4aac-ae2a-e942e99006b8_at_d4g2000prg.googlegroups.com>
Cimode wrote:
> On 21 mar, 14:30, Eric <e..._at_deptj.demon.co.uk> wrote:
> > On 2008-03-20, topmind <topm..._at_technologist.com> wrote:
> >
> >
> >
> >
> >
> > > Eric wrote:
> > >> On 2008-03-20, topmind <topm..._at_technologist.com> wrote:
> > >> > On Mar 20, 11:43 am, frebe <freb..._at_gmail.com> wrote:
> > >> >> On 20 Mar, 18:39, topmind <topm..._at_technologist.com> wrote:
> >
> > >> >> > David Cressey wrote:
> > >> >> > > "Eric" <e..._at_deptj.demon.co.uk> wrote in message
> >
> > >> >> > > > EAV is a way of misusing an RDBMS, and could be used for any subject
> > >> >> > > > domain - and your schema description sounds like EAV.
> >
> > >> >> > EAV (attribute/value pair tables) is not always bad. It is one
> > >> >> > approach to allowing user-definable "columns" and/or times when
> > >> >> > dynamicy is needed so that a DBA does not have to do the new-column-
> > >> >> > shuffle all the time.
> >
> > >> >> > I agree it can be a performance killer in some circumstances, but
> > >> >> > often that's the tradeoff for flexibility.
> >
> > >> >> Using existing mainstream software development tools, I would agree
> > >> >> that EAV is an necessary evil in many cases. The obvious solutions is
> > >> >> of course to have better 4GL tools, which allow developers to more
> > >> >> easily add fields in the database and the GUI. A while ago I had the
> > >> >> doubtful pleasure of working with an application which was 100% EAV,
> > >> >> and the flaws was pretty obvious. I have never seen such bad
> > >> >> performance.
> >
> > >> >> //frebe
> >
> > >> >http://www.c2.com/cgi/wiki?DynamicRelational
> >
> > >> What on earth are you trying to prove by referencing that?
> >
> > > It was not to "prove" anything, but show *potential features* of a
> > > dynamic relational system. (Some don't like dynamic relational, but
> > > that's like the ol' Smalltalk versus Eiffel fights, except with
> > > relational instead of app langs.)
> >
> > And how much of it did you write? Looks to me like adding flexibility to
> > the RM by removing defining features, also like solving a non-existent
> > problem. But both of those are separate arguments.
>
> Well put. The definition of OO *flexbility* can pretty much be summed
> up to *no constraints, freedom*...Same ol story..
I'm not sure I agree with this being the difference, but I'll save that definition fight for another day.
There is often a need to add columns without a lot of red-tape. You may argue that the red-tape "should" be in place to ensure clean schemas, but the environment may want a more "organic" approach, even if it means more clean-up effort later. It is a management/payer decision as to how to allocate those effort trade-offs.
If the customer wants the ability to add new columns without programmer or DBA intervention, we should have technology that can deliver that. "It's not good for you" is NOT an acceptable answer.
Plus, the approach described allows one to incrementally add constraints etc. as needed.
-T- Received on Tue Mar 25 2008 - 18:56:04 CET