Re: Property sheet, ad hoc, property page, flexible data

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 24 Jul 2005 10:14:12 -0700
Message-ID: <1122225252.681294.147290_at_g49g2000cwa.googlegroups.com>


David Cressey wrote:
> "AC" <AC_at_No.spam> wrote in message news:TkFEe.4555$6M3.3607@trnddc03...
>
> PMFJI.
>
> The fundamental problem with user defined attributes is not a theoretical
> one. It's one of conflicts between two incompatible requirements of the
> users.
> fine

Strongly agree.

Some more problems:

Dawn describes two possible approaches.
approach 1: add columns "UserDef1", "UserDef2" approach 2: additional table, with three columns: FK, Name, Value

The first one is just frightening. It's not even in first normal form, and it will exhaust its expanision capacity quickly.

The second one is better. Amusingly, I would describe that solution as being one that actually has well-defined semantics. The semantics are that the first column specifies the entity being described, the second is the name of the quality being described, and the third is the value for that quality. Not a *lot* of semantics there, but at least it's well-defined. Note that I would not agree with Dawn as describing this as mixing metadata and data, because the values in the name column *aren't* metadata, since we don't know what they mean, other than "they are names."

Another significant issue with these approaches is that they both do not have any way of allowing any structure in the user defined data; you're limited to exactly whatever domains you allow up front; probably int and string, say, but certainly not, say, three pairs of int/float tuples and a list of x, y points.

Marshall Received on Sun Jul 24 2005 - 19:14:12 CEST

Original text of this message