Re: EAV (Re: Object-relational impedence)

From: Ed Prochak <edprochak_at_gmail.com>
Date: Fri, 28 Mar 2008 11:49:03 -0700 (PDT)
Message-ID: <fe33d7f7-f030-4109-a3f8-891b1033796a_at_n58g2000hsf.googlegroups.com>


On Mar 27, 4:41 pm, topmind <topm..._at_technologist.com> wrote:
> (addendum)
>
> For an example of the need for flexible columns/attributes, consider a
> relational-based GUI system where widget state and info are tracked in
> some kind of RDBMS. We want it to be able to add new widgets from
> different vendors without each widget needing its own table(s) (unless
> its a really special need).
>
> There seems to be a need for either a EAV table (row-based dynamism)
> or Dynamic Relational (column-based dynamism) of some kind so that
> attributes that are not known up-front can be tracked.
>
> If you suggest otherwise, please present your design.
>
> -T-

Long ago when I first encountered databases, I did some work on a drawing system. Based on that I would suggest that your EAV approach is not the only solution.

You already describe some attributes that are common to all widgets: state (runtime status or release status or ??) info (content?)
vendor

Now if different vendor are supplying widgets, there must be some common interface to your GUI tool. With that defined you have all you need for any widget. IOW add the interface data and you are done. For example the drawing system included the command sequences to draw the object. (I cannot now remember if that was one long column or a separate table.)

So what is so complicated about the GUI interface you are thinking of that --requires-- EAV? There are ways to do extensible designs without EAV. Received on Fri Mar 28 2008 - 19:49:03 CET

Original text of this message