all about databases
WELCOME.NEWS.ARTICLES.EVENTS.WHITE PAPERS.BLOGS.CONTACT US.
Copyright © All rights reserved. Made By Serif. Terms of use | Privacy policy
WELCOME.NEWS.ARTICLES.EVENTS.WHITE PAPERS.BLOGS.CONTACT US.
the                                                 site

The Database Site

The Database Site is your web resource for database news, information, tips and guidance. Keep up-to-date on your favorite DBMS and more>.     

Database Fundamentals

What is a database? I bet most folks reading this think they know the answer to that question. I'd also bet that many of you are wrong. DB2 is not a database; neither are MySQL, Oracle or SQL Server. Each of these is a DBMS, or Database Management System. You can use DB2 (or Informix or SQL Server) to create a database, but DB2, in and of itself, is not a database.  more>

For decades, companies have been benefiting from proven software change management (SCM) principles. Processes like file locking, check in/check out, compare and merge, and rollbacks have helped them deliver modifications to applications in a more productive, yet more controlled fashion.  

 

But, traditional SCM concepts don’t necessarily fit in the database world. Databases are constructed differently than traditional software code (such as Java or .NET), and therefore, traditional SCM tools and procedures cannot be applied. As a result, there has been a major disconnect between SCM and database development activities.

 

SCM is controlled via a repository supporting functions against files (program source code). It typically offers capabilities for file locking, check out/check in, baselining, support for rolling back changes, comparing and merging, build / deployment, and so on.

 

But unlike a software application, a database is not a collection of files.  To the file system, for example, it is often visible as a single huge file. Another example is the concept of the SCM 'vault' – when you check in traditional code changes, you update a protected copy of the code and track revisions, while doing the actual development of your code on a local copy of your project.

 

But a database is a central resource that everyone accesses and changes at the same time.  You rarely make copies of it for each developer (in some situations this is actually done, but then you have to start dealing with constant synchronization to ensure consistency). You also have to deal with different levels of revision management.  Some changes, such as procedures, are code-like, and some are not.  Those are changes to the actual content of a table that would influence the application. Additionally, there is no “debug” environment.  

 

In other words, database code is a completely different “animal” than traditional code.  

 

Then, there’s the issue of moving changes from development to QA, integration, and production. With software code, this involves little more than simply copying and registering files. But, database objects can’t just be moved; it’s a bit more complex than that.  You can’t just put a changed table from development into production, because you would lose all of your production content.  

 

Unlike SCM solutions, which keep detailed logs of all changes, database developers often needed to create hard-copy lists depicting database alterations. Believe it or not, we’ve actually seen a developer who kept track of the modifications he made on post-it notes scattered across his desk and monitor.  

 

A common work around for database change is to export the database definition language (DDL) for defining data structures, and save them in a traditional SCM tool as files. But this is not a closed-loop process. No one can make sure developers actually remember to check in every change they introduce. And what happens if someone just updates the database and doesn’t update the SCM? How can content changes be handled? A changed value of a parameter (in a lookup, or metadata table, etc.) can change the behavior of your application, and clearly has to be managed. But how?

 

Then, code has to be manually written to enable the alteration of database structures, without data loss.

 

First-Generation Solutions

 

Clearly, automation was much needed. So, next came the first generation of database change management tools. These were basically automated “compare and sync”-type tools that allowed different environments to be measured against each other.     more>  

Corporate data is more important than ever, and production databases store the most important data. Managing and  documenting database change in compliance with regulations is increasingly complicated.

 

It is the mission of the database site to make it easier for individuals and organizations to find what they need to better understand database systems.

> IBM DB2

> Oracle

 

> Microsoft SQL Server

> Netezza

> Teradata

> MySQL

> EnterpriseDB

The History and Future of 
Database Change Management
What is a Database?

> Informix

> Sybase Adaptive Server

> Ingres

> Non-relational DBMS

> XML Database Products

> Apache Derby

database
	   vendors
mission

> PostgreSQL

Data + Technology Today

Check out Craig S. Mullins’ blog on data and database technology. more>

Database Tips, Tricks, Scripts, & Techniques

A treasure trove of tips, tricks, and scripts for the practicing DBA or database professional... more>

Feature Article:
August 2010