Relational Databases and SQL

SQL is the language of relational databases. A simple query like a one-table SELECT will be more or less the same whether you’re using a tiny database
like mSQL or an expensive behemoth like Oracle. The big advantage for you, the web developer, is that, after you learn SQL, you will be able to interact with numerous databases across all platforms without a steep retraining curve. Just imagine how horrible life would be if Oracle, MySQL, and SQL Server all had entirely different sets of commands for putting data in and getting data out of their stores — as if Oracle used SELECT to ask for data sets, MySQL used VALJ (the developers are Swedish, you know), and SQL Server used FIND IT IN THIS TABLE (to better match the vocabulary of Windows). SQL is the common vocabulary and syntax that will save you from this nightmare. There are differences among products, and in their implementations of the SQL standard and the extensions they each define to that standard, but it’s better to have 80 percent in common and 20 percent different than the other way around.

SQL Standards

According to Andrew Taylor, original inventor of SQL, SQL does not stand for Structured Query Language (or anything else for that matter). But for the rest of the world, it does now. As you would expect from the (non-) title, SQL represents a stricter and more general method of data storage than the previous standard of flat-file DBM-style databases. SQL is a standard under both the American National Standards Institute (ANSI) and the Equipment Managers Council of America (ECMA); both are international standards-maintenance organizations. You can read the standards on payment of a fee to these organizations:

• www.ansi.org
• www.ecma.org

However, within the general guidelines of the standard there are considerable differences among the products of individual companies and open source database development organizations. The past few years, for instance, have seen the rapid growth of so-called object-relational databases, as well as
of SQL products specifically slanted toward the web market. The key to choosing a database is to be selfish, or at least supremely self-centered. You will see plenty of unusually virulent postings out there opining that a certain advanced database feature (like triggers or cross joins) is a “must,” and any SQL installation without this feature hardly deserves the name. Take this stuff with a grain of salt. It’s far better to make a blind shopping list of functions you need in order of importance and then go out looking for the product that best meets your requirements.

That said, a good deal of SQL really is pretty standardized. You will be using a few SQL statements over and over and over, no matter which specific product you choose to deploy.