Re: EAV (Re: Object-relational impedence)

From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 27 Mar 2008 23:29:20 GMT
Message-ID: <k5WGj.30388$R84.17469_at_newssvr25.news.prodigy.net>


"topmind" <topmind_at_technologist.com> wrote in message news:a8855c5d-1e3f-46ef-a99a-5c09b94bfba5_at_u10g2000prn.googlegroups.com...
> (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.
>

Well it's really simple. You have a single table with attributes that are common to all possible widgets, and when a set of attributes that are not known up front needs to be tracked, a new table or set of tables is created to house the set of attributes that references the table with the common attributes. It's really very simple and doesn't require a special dynamism (Is that the correct use of that word?) mechanism. In fact, this design is also very economical, since each referencing table only contains rows for those widgets that possess that attribute (or set of attributes), and there is no need to record the attribute names over and over again. Note that each widget does not necessarily need its own table: there could be widgets that possess attribute X, those that possess attribute Y, those that possess attributes X and Y, etc. The widgets that possess attributes X and Y would have rows in the table housing X attributes and the table housing Y attributes as well as the table housing the common attributes. Received on Fri Mar 28 2008 - 00:29:20 CET

Original text of this message