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

"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1122168791.730962.143770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> AC wrote:
>> "mAsterdam" <mAsterdam@xxxxxxxxxxx> wrote in message
>> news:42dd8886$0$76953$e4fe514c@xxxxxxxxxxxxxxxxx
>> > 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/>
> 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.
>
<snip/>
> 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
<snip/>
> Cheers! --dawn

Thanks for the reply and the search string suggestion, Dawn. We considered
tag/value storage but decided that it wouldn't work as well as defining each
field. The problem with pre-creation of the fields (UserDef1, UserDef2,
etc) is that you would be stuck with for example 5 text fields, 6 ints, 2
date_time, etc. This would be limitation that does not appear to have much
benefit.

Regards --AC


.