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

AC wrote:
> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:42dd8886$0$76953$e4fe514c_at_news.xs4all.nl...
> > AC wrote:
> >> ...I want to create "base" tables with fields that are intrinsic to the
> >> application. I also want to allow the customers using the application to
> >> be able to create their own fields so that they can easily customize the
> >> application.
> <snip/>
> >
> > If this group would have a FAQ, this Q would be in it.
> > For now you'll have to do with googling the archives.
> >
> > The short answer is: don't go that way, you'll get the worst
> > of both worlds.
> <snip/>
> > It's not a bad question, but I don't like going over the same arguments
> > every time it pops up.
>
> Can you post the search string I should use? I did google which is why I
> created the subject I did. So that others that were searching for this type
> of answer could find it. I don't know how others have described this
> scenario. I get a lot of pages on property sheets for programming controls.
> I know that this type of setup was used by Symantec ACT but didn't find
> references to that either.

I get a couple of hits on the string

user-defined-attributes

in cdt in googlegroups and I suspect some variations would also yield results.

The bottom line is that when someone who "does" databases is asked how to support user-defined attributes, they often tell the user that their requirements are not as important as the integrity of the database and that there is simply no way they can figure out how to design a solution that mitigates the risks within reason.

I have no problem letting users define attributes, but I don't often use a SQL-DBMS. Even if using a SQL-DBMS, there are multiple ways to try to meet the user requirements. You can assess the risk to your company if you were to toss in a few strings, ints, and floats with names like M1, M2, or userDef1, userDef2 or User_Def_1, User_Def_2 ... (just understand that some DBAs in the audience are certain I'm either stupid or ignorant when they read this). Place such attributes (with unique names) in relations that are likely spots for additions, document it well, and make UI's to collect the data.

Another approach is one where you store tag & value in two separate attributes so they can name a value and enter it, thereby mixing metadata with data. This is, of course, one of the "never do this" commandments, but, again, you need to assess the cost vs benefits and mitigate risks.

Your users will thank you. Scratch that as overly optimistic, but if you have determined that they and the company would be more productive with these attributes when you did your risk / cost assessment, then you just might have done something good.

Cheers! --dawn Received on Sun Jul 24 2005 - 03:33:11 CEST