Custom Database Design

Give us a lead.

Our moms taught us to share.

Because so much of our efficiency comes from open-source sharing and re-use of successful code modules, we believe in the power of open source. So much so that we frequently share our own code with other developers; yes, even our competitors.

We know .NET inside and out.

Microsoft's ASP.NET is a framework for application development which serves as a foundation upon which Agile teams may build web sites, web applications, web services, smart client applications, and even Silverlight animations. .NET custom software may be built in a handful of languages, but the industry has standardized around C# (as has Headspring). Headspring has chosen to make .NET Agile development in C# one of its core competencies as the majority of its key players come to Headspring with extensive ASP.NET backgrounds including working knowledge of and substantial contributions to many open source additions which allow for improvements upon or more efficiency with the standard capabilities of .NET.

Our Process

At Headspring Systems we standardize custom database design around a process which allows us to easily rollout changes in a predictable, disaster-free manner. We save all incremental additions to our schemas as SQL scripts within our projects and let NAnt build scripts update database instances as needed based upon the SQL scripts. Specifically:

Every machine that runs an instance of one of our applications, be it the production server, the staging server, or a pair-programming station for development, runs a separate instance of the database schema. Any one independent instance of code has a separate and exclusive instance of the schema. Thus, there is never a situation in which two deployments of source code (which may potentially vary) share data. This ensures that errors of interaction that occur between code and schema occur local to one machine and are:
- the product of local changes which have occurred since the code was last updated from the source code repository
- resolved before refined code may be committed anew to the source code repository
These conditions are largely guaranteed by integration tests and an operating policy in which developers must run all unit and integration tests as part of a "check-in dance" before committing changes.

In scenarios in which untested code is committed to a repository, typically a NAnt script which builds code to a staging server will fail based upon an inability to run integration tests successfully (a standard requirement of our build scripts) and the broken build will alert the Agile team developing the application of the problem by way of Cruise Control.

At the production server it is improbable that code and schema will not be what has emerged from the code repository guaranteed to work by unit and integration tests. The only conceivable way such could occur would be by way of a manual change to either code or schema after their deployment. It is thus true to say that the build-to-production process eliminates all bugs and human error from updates.

One database table within any of our schemas will be dedicated to managing a list of SQL scripts run against the database. A "Database" project within any of our solutions will keep the SQL scripts needed to build the schema. As SQL scripts are added and committed to source code the processes for deploying new code to production/staging servers and pair-programming workstations will, first, gauge which of the scripts have already been run against the relevant schema instance and, moreover, run any outstanding scripts. It is by this means that schema updates are painlessly rolled out and integrated with instances of an application's schema.

Codecampserver is an open source example of custom application development which utilizes the before mentioned approach to custom database development.

Take A Look

Proudly headquartered in Austin, Texas