Re: Testing relational databases
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 09 Jul 2006 19:32:18 GMT
Message-ID: <6Rcsg.8373$pu3.186991_at_ursa-nb00s0.nbnet.nb.ca>
>>JXStern wrote:
>>>I don't get it, why is the book title "Refactoring Databases" if it's
>>>mostly about testing?
>>Unfortunately, the majority of uses of RDBMs is to only persist
>>mission-critical data. The vast majority of development done with dbms
>>that I've come across (from all sizes of company - startups - medium -
>>large multinational corps) have all done the same.
>>
>>Lots of tables, several referential constraints, a fair few uniqueness
>>constraints, and db links and a sprinkling of joins.
>>
>>As for business logic that could be modeled using the RM, its tended to be
>>either in the 'application' code base (C++, Java, etc) or as stored
>>procedures.
>>
>>So, whilst Scott may have made a better impression with the guys over in
>>c.d.t he can certainly help the rest of the RDBM users.... and lets face
>>it - there's more of them.
Date: Sun, 09 Jul 2006 19:32:18 GMT
Message-ID: <6Rcsg.8373$pu3.186991_at_ursa-nb00s0.nbnet.nb.ca>
Phlip wrote:
> AndrewMcDonagh wrote: >
>>JXStern wrote:
>
>>>I don't get it, why is the book title "Refactoring Databases" if it's
>>>mostly about testing?
> > What technique, beginning with R, should you never do without unit tests? >
>>Unfortunately, the majority of uses of RDBMs is to only persist
>>mission-critical data. The vast majority of development done with dbms
>>that I've come across (from all sizes of company - startups - medium -
>>large multinational corps) have all done the same.
>>
>>Lots of tables, several referential constraints, a fair few uniqueness
>>constraints, and db links and a sprinkling of joins.
>>
>>As for business logic that could be modeled using the RM, its tended to be
>>either in the 'application' code base (C++, Java, etc) or as stored
>>procedures.
>>
>>So, whilst Scott may have made a better impression with the guys over in
>>c.d.t he can certainly help the rest of the RDBM users.... and lets face
>>it - there's more of them.
One wonders whether Andrew thinks that's a good thing and whether he thinks the lopsided ratio should continue to grow. After all, he is simply agreeing with many of us that the vast majority of practitioners in our field are uneducated, misinformed and unaware of their predicament.
> I thought the book was going to be about making sure you can refactor a > database while maintaining an upgrade path from the last design to the next > one, so your customers don't need to data-enter all their data again, once > per new version. > > Put another way, the decision to refactor the database should be made > at-whim, without regard to any up-front design. Otherwise the data design > will be timid, like you said, or will be crufty.
Or, as is too often the case, it will be entirely arbitrary--even random. Received on Sun Jul 09 2006 - 21:32:18 CEST