Follow @DBDebunk Follow @ThePostWest

Working on a book of 2000-2006 material from the old dbdebunk.com, I came across the following 10/29/04 exchange. MySQL has probably improved--although, adding features post-hoc to products that were not explicitly designed for such upgrading is always problematic--more complex and limited than necessary. However, education and foundation knowledge have become worse and, from a foundational perspective, so have products and practices.

JG:  fell asleep dreaming of column constraints. I woke up thinking of foreign keys. I've been married to MySQL for so long that I had no idea all of these other things were possible!

Using a database and not knowing about foreign keys? My immediate reaction was to be astounded. However, he just happens to have begun with the least-robust database product on the market, and his learning is (evidently) confined to whatever product he happens to be using.

Astounded? Nah, standard operating procedure.
Here are some old weekly quotes:

Sorry to bother you with MySQL, but I don't have a clue about it ... We are running a little MySQL database here and nobody is really familiar with it (to put it politely). Now we are discussing a backup "strategy" for it. The word is that you simply need to copy the data files to a different disk (or tape) and that's it. Is that right? Even when the database is running and open for users? Does anybody have some hints on how to back up MySQL databases?
--ORACLE mailing list

A PRIMARY KEY and a UNIQUE index are very similar. In fact, a PRIMARY KEY is just a UNIQUE index with the name PRIMARY. This means that a table may contain only one PRIMARY KEY because you can't have two indexes with the same name.
--PD, mySQL

The FOREIGN KEY syntax in MySQL exists only for compatibility with other SQL vendors' CREATE TABLE commands; it doesn't do anything. The FOREIGN KEY syntax without ON DELETE ... is mostly used for documentation purposes. Some ODBC applications may use this to produce automatic WHERE clauses, but this is usually easy to override. FOREIGN KEY is sometimes used as a constraint check, but this check is unnecessary in practice if rows are inserted into the tables in the right order. MySQL only supports these clauses because some applications require them to exist (regardless of whether or not they work). In MySQL, you can work around the problem of ON DELETE ... not being implemented by adding the appropriate DELETE statement to an application when you delete records from a table that has a foreign key. In practice this is as quick (in some cases quicker) and much more portable than using foreign keys.
--mySQL designer

MySQL allows you to create a column of type CHAR(0). This is mainly useful when you have to be compliant with some old applications that depend on the existence of a column but that do not actually use the value. This is also quite nice when you need a column that only can take 2 values: A CHAR(0), that is not defined as NOT NULL, will occupy only one bit and can take only 2 values: NULL or "".
--mySQL manual

MySQL is not a toy database - it is far superior to many I have used in my long career. The lack of constraints is not a weakness. It is eminently possible to create reliable applications without the need for database constraints - I should know because I have designed and built many applications that did not use database constraints (mainly because they were not available). Developers only rely on database constraints to circumvent their sloppy code. Anything that can be done within the database can also be done within application code. I have seen what happens when poor programmers try to shift logic from their code into the database - they get it wrong and then blame the database for their incompetence.

I am used to designing and building applications without relying on database 'features', so I write my code accordingly. It also means that the logic is maintained in one place and not it bits and pieces here and there.
--TM, groups.google.com, comp.lang.php

One thing that MySQL will not be including is XML support. In an interview with InfoWorld, Marten Mickos, the company's CEO, is reported as saying that "if XML in the database becomes mainstream, we will do it. My personal view is that the relational model is about as complicated as it can get before it gets too complicated".

I agree. In fact I would go further I think the relational model has been extended beyond its natural limits. The corollary to this is that from a technical perspective it makes much more sense to use, say, Software AG's Tamino as an XML database that sits side by side with your relational database, than it does to try and cram this quart into a relational pint pot.
--RH, Archonet Ltd.

And this is neither limited to MySQL, nor exhaustive, nor the worst.

Starting with a product--that is a vast majority of practitioners work with those products in "cookbook mode", without really understanding their pros or cons, or those of their work. Even the "better" products, they are all poor SQL implementations of the RDM created by people with a similar background, they don’t know fundamentals either [Codd and Date are on record that the authors of SQL did not have a good grasp of the RDM and Larry Ellison was a marketeer].

This is a systemic problem that perpetuates itself without a solution and worsens rather than improves, particularly with Google, Facebook, Twitter and Microsoft getting involved in the school and academic systems, substituting training for education. Here's an example:

By technical I mean the point of this class is not to teach theory, not to teach opinion, not to teach buzz words and not to teach what any corporation, including Oracle, wants taught. Technical means code! And while we teach the course using Oracle we cover aspects of DB2, Informix, SQL Server, and Sybase too. We can't get free copies of every RDBMS on the market for the students and, quite frankly, the students have expressed close to zero interest in DB2, Informix, and Sybase. At least here in the Northwest the only players are Oracle and Microsoft.

Perhaps not in some 19th century view of the purpose of academia but most certainly incorrect in terms of how it views its mission at present. And if not at the university where is the student to gain the expertise and where is the organization to gain skilled employees? We are in a product-oriented industry. There are few analogs in medicine or engineering but they most certainly do exist. One does not learn how to install a generic pacemaker ... one learns to install a particular brand of pacemaker. One does not learn about cancer treatment as a generic subject but rather as pharmacology with the application of specific branded medications in specific cases. There is no difference between telling a physician to give Xeloda for breast cancer and telling a software engineer to apply Real Application Clusters for high availability: Both are product specific solutions to technical problems.
--DM, Oracle Application Development Certificate, University of Washington

[Apparently, the  author is oblivious to the 6-7 years of medical school and what is learned there].

Dumb down. Conform. No education, no thinking, just tool training, coding. No culture or society falling into this has ever survived for long and the signs are already on the wall for the PostWest.