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.
