Re: EAV (Re: Object-relational impedence)

From: topmind <topmind_at_technologist.com>
Date: Fri, 28 Mar 2008 16:04:08 -0700 (PDT)
Message-ID: <28b25518-5791-485c-91d5-ae34f1fd60dd_at_i12g2000prf.googlegroups.com>


Ed Prochak wrote:
> 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.)

I am not sure what you mean. I agree that common stuff should be in a single shared table ("Widgets" perhaps). But the custom and future attributes that cannot be anticipated for in advance have to go somewhere. These are the bugaboos.

Perhaps you mean that each widget manage its own attributes if they are not the common ones. That makes it hard to copy and test and debug. That is the OOP way, not the relational way. Each widget then invents or re-implements its own little collection-handling engine and/ or interface. Encapsulation in this way is anti-relational.

>
> 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.
I'll tell you what, let's test this. Create your idea of the standard Widget table with common/likely attributes. I and possibly others will then suggest widgets or widget features and you describe how your schema and/or installer will handle them.

I'll even help you out with a suggested table for starts:

 table: Widgets


 widgetID    // internal-generated
 widgetName  // reference name (possible alternative to auto-ID)
 widgetType   // button, textbox, etc. Foreign key to WidgetTypes
table
 widgetTitle
 containerRef // foreign key to container widget ID  orderSequence // sequence if in flow-based layout (double)  X
 Y
 Z // depth
 defaultValue // (may not be needed if "content" can be used instead)  content
 isReadOnly
 isHidden
 formatTemplate // formatting/validation template string (such as Reg.Ex's)
 columnRef // DB column reference for "bound" widgets  tableRef // DB column reference for "bound" widgets  backColor
 foreColor
 borderColor
 styleRef // style ID

Note that many of these are optional.

-T- Received on Sat Mar 29 2008 - 00:04:08 CET

Original text of this message