Re: User-defined fields

carl_willis-ford_at_sra.com (Carl Willis-Ford) wrote in news:3f7c0afa.0201070652.403d6ef9_at_posting.google.com:

> I work primarily with Oracle, but this question is relevant to just
> about any RDBMS, I would think.
>
> I have a customer wanting an 'extremely flexible, scalable' database
> design. Of course, they already have the solution...design a standard
> relational database, but then allow for users to add their own fields
> as they need new things to be stored in the database.
>
> The customer doesn't have details about how the RDBMS will work with
> these fields, just saying that the 'database experts' can figure it
> out.
>
> Essentially, they talk about tables describing relationships, with the
> records in the tables holding 'metadata' about the data as well as the
> data itself. (not a good description, I know, but that's what I have
> right now...)
>
> My concerns are centered on things like how to handle FK's, indexing,
> ad-hoc query tools, how the optimizer will work, etc.
>
> I see out on the web that there are many COTS type products that use
> databases and advertise customized or user-defined fields, but I
> haven't seen any white papers or other treatises on this idea.
>
> Wondering if anyone could share some insight here.
>
> thanks!

To some degree, Siebel uses this approach. PK/FK relationships are maintained at the "business level" and NOT at the database level.

Each of the major "base" tables have unused fields of varying datatypes that customers can use for their own data files.

Each of the major "base" tables has at least one extension (base_X) table with more user defined data fields.

Siebel requires a DBA or similarly trained experienced developer to extend/customize the application to make use of these fields.

If/when the customizations are minor, the buy vs. make trade-off tilts to buy. After some level of additional customization, the maintainability, flexibility & speed tilts to make your own custom app.

I wish your customer well, but I doubt this is a viable product.

HTH & YMMV! Received on Mon Jan 07 2002 - 19:40:27 CST