Re: Looking for a discussion about generic datamodels
Date: Fri, 02 Sep 2005 14:33:45 GMT
Message-ID: <dpZRe.352243$5V4.317585_at_pd7tw3no>
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
>
sounds right to me. another point - if we're talking about a dbms, the main 'con' is that it is basically a con game. sometimes it's sold to the customer as a 'framework'. really a shell game where the the dbms's ability to manipulate the customer's model of the customer data is discarded and the dbms is demeaned becoming not much more than a physical access method. so it's up to the 'framework' to invent new verbs, catalog et cetera. whether these are complete, sufficient, safe, portable and so forth is entirely up for grabs, which results in the main 'pro' - "jobs for the boys" as the consultants' union might say. meanwhile the customer believes, wrongly, that his investment in the system software has long-term value but he is actually being screwed. doubtful whether there is any "schema" that can be discussed logically - maintenance becomes either a very crippled proposition with limited choices for extension or every new function becomes a separate adhoc effort. normalization and other advantages are thrown out the window along with the baby and the bath water - might as well invent your own dbms from scratch.
p Received on Fri Sep 02 2005 - 16:33:45 CEST