SQL in Action
SQL is a very utilitarian database environment. Normally, with every
database management system comes a new language for construction, querying,
reporting, and design. After a while, it becomes rather tiresome, especially
with the multiple upgrades to each system, to keep working with different
databases. With SQL, however, the language is standardized, thus any
SQL-compliant database will adhere to at least some base language
structures, affording the development staff greater flexibility in their
designs as they can build with relative ease and confidence.
To further expound upon this aspect of SQL, imagine you’re the development
department of a large firm. You have three other departments: marketing,
finance, and technical services. Marketing has an Access 2.0 database,
finance is running an older FoxPro database, and technical services is
running a Paradox database, which in sum makes life a nightmare for your
development team should they ever wish to exchange data between systems.
The best plan for a workplace like this would be to upsize everyone to SQL
server databases, and work from there, decreasing development time and
increasing the amount of data interchange between departments. As an
alternative, you may not have to move everyone to SQL servers, but ensure
that whatever they are using is SQL-compliant, which would also make the
developers’ lives easier.
