Re: Looking for a discussion about generic datamodels

From: BobTheDataBaseBoy <"xxx>
Date: Fri, 02 Sep 2005 14:02:56 -0400
Message-ID: <7dadnbRcT5FWDoXeRVn-2A@rcn.net>

David Portas wrote:

>>the choice for such a data model is defended by the
>>argumentation that new conceptual tables and columns can be added
>>without modification of the data model.

>
>
> Why would that be an advantage? Is it because your RDBMS* is hard to
> use or because the developers lack expertise. In that case the obvious
> solution is to get new software or new staff.
>
> A common excuse for the design you've described is that the business
> doesn't know or doesn't care to define the data requirements up front
> and wants a "cheap" way to support metadata that is "user-defined" at
> some point in the future. The problem is that most of those users will
> lack the expertise, the time, or the inclination to do a proper job of
> designing a data model. The user-defined approach therefore costs more
> in the longer term by reducing the data's validity and usefulness.
>
> (* I'm assuming throughout that we are discussing Relational databases
> or at least SQL databases, please tell me if I'm wrong)
>
> David Portas
>

bill of material processors (now mostly referred to as ERP because they include Job Control) use just this kind of data structure. there really isn't much choice if the software producer wants to sell to more than one company in one industry. if you're building a system for one business, then you can build specific tables to the business process definitions.

BTDBB Received on Fri Sep 02 2005 - 13:02:56 CDT