Re: How to model searchable properties of an entity

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Sat, 14 Aug 2004 12:59:14 -0500
Message-ID: <cfljtp$ilr$>

"Dilip Angal" <> wrote in message
> May be I did not clarify my problem.
> My business needs are I need to allow users to define attributes on
> the fly.
> This is not the DBA's fault.

Scenarios such as this are really quite common and typically toss SQL-DBMS folks into either significant design errors or dog ugly designs (from my perspective, that is, although they are elegant in their own way, see Celko).

If you are saddled with an RDBMS, then this might not be helpful at all, but if you are positioned to use an old-fashioned non-RDBMS solution (or a new agile database, perhaps) you might want a scenario like this:

Don't have users defining stored data (what would be base tables in an RDBMS) but permit them to define derived data, aka UDF's, aka virtual fields. In particular, they could be granted the ability to provide a synonym for an attribute and a redefinition of the type for that attribute (DBA's are rolling their eyes). Then I can provide attributes named ATTR1, ATTR2, ATTR3, etc and allow these to be redefined (by the user) as either single-valued attributes or multi-valued lists of whatever type is needed. This is a common approach when using IBM U2 databases, for example (UniData or UniVerse) and is employed by at least one application software vendor I know who has the best profitability over time (> 30 years) of just about any application software provider (IIRC).

Although I would not recommend it, you could even permit the same "dummy field" to be redefined differently for different records, with synonyms for the very same field, even if it is employed as a number for one subclass of this entity and alpha for another.

It is this type of flexibility and the related maintenance complexities that RDBMS's were built to avoid. However, they seem to have thrown the baby out with the bath water.

Signed --old DP professional Received on Sat Aug 14 2004 - 19:59:14 CEST

Original text of this message