Re: Testing relational databases

From: AndrewMcDonagh <newsamd_at_amc.com>
Date: Sun, 09 Jul 2006 23:52:37 +0100
Message-ID: <e8s1cb$o17$1@news.freedom2surf.net>

Bob Badour wrote:

> 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'm agreeing but I dont think we should live with it.

I dont think its feasible that the vast majority of DB developers using RDBMs can become as proficient at designing them to make the most use from the technology.

Whilst I'm certainly not advocating the reduction of tools to to the lowest common denominator skillset - I feel there will be a different technology arriving that will at worst hide these intrinsically difficult concepts, at best, remove them all together.

Much like 2nd generation languages (usually referred to as Assembly languages) meant we no longer needed to develop in machine code.

I have no idea what this will be - but I believe it will happen.

I'm currently involved in a DSL project which will allow the users to read and understand and say, what it is they want the system to do. It controls and responses to events from a large robot storage system. The actual API of the robotic storage system is a set of RDBMs tables - not a programming language like C, Java, etc.

It follows a lot of the same principles that human languages do - words, sentences, context, etc.

I have no idea if this is the kind of thing that will replace or hide the difficult (for most) stuff - but its certainly a start.

> 
> 

>> 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 - 17:52:37 CDT