Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Disconnected database development: solving a problem that needn't exist

By Phil Factor,

I was rather late to the debate about the relative virtues of single-user vs. shared working, in the course of database development. Actually, I suspect that Database Developers like me generally use both as appropriate. I have a sandbox server in which I reign supreme, as a user with god-like powers. It has several instances, each of which is a separate release of SQL Server, with SQL Server 2000 as the base instance. I do a lot of my work there, but I always use a shared team development server for the final integration of what I develop. Here, I'm just a prole amongst users, and the Development DBA reigns supreme, with the test team as attack dogs. Everything goes into source control as it is developed, so nothing gets lost.

The developers who are forced to use the 'disconnected' or 'declarative database development' model are the ones I pity. In this technique, you don't work on a database, but a 'model' of it, and the results of your labors is built into the database in a separate integration phase. I've pored through the literature to try to detect a really good reason for using this way of developing databases. Surely there must be a valid objective for creating an elaborate integration phase in the building of an application, even though a relational database, by its essentially multi-user nature, is self-integrating. Is this an elaborate solution to a problem that shouldn't exist?

A disconnected model is only really needed in the absence of a properly-defined database interface. We, as developers, create a rod for our own backs by insisting on treating a database in a way we wouldn't treat an object, let alone an assembly or namespace. The same developers who are so careful with dependencies and interfaces; who create special mediator components, and ensure that only certain methods or collections are public, seem often to go completely crazy with a database and insist on completely unfettered access to it. The knock-on problems are similar to those you would find in a purely C# application if you did the same thing to an assembly. The whole database has to be an application project dependency. If two applications use the same database in an identical anarchic way, then the result is the same as the one you'd get if two applications treated a shared assembly in the same way.

The disconnected database development model seems to try to mimic application development by removing all the intrinsic strengths of 'traditional' database development. It is a high price to pay as a way of reducing those problems of integration and deployment that have their origins more in poor architectural planning than in flaws in the development or configuration-management process.

Phil Factor.

Total article views: 115 | Views in the last 30 days: 5
 
Related Articles
ARTICLE

The myth of the ‘shared development model’

Phil Factor fluffs the feathers of the shared sandbox model of development.

FORUM

Modeling relational databases

Modeling relational databases

FORUM

Database Integrity Error

Database Integrity Error

ARTICLE

SQL Server Database Development Methodologies using SQL Compare

This 3-part sponsored article surveys several different methodologies for database development, exam...

ARTICLE

SQL Server Database Development Methodologies using SQL Compare

This 3-part sponsored article surveys several different methodologies for database development, exam...

Tags
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones