If I were designing a oil refinery, I wouldn\'t expect that materials from different vendors would not comply with published standards in subtle yet important ways. Pipework, v
In the software industry you have some standards that are really standards, i.e., products that don't comply with them just don't work. File specifications fall into that category. But then you also have "standards" that are more like guidelines: they may defined as standards with point-by-point definitions, but routinely implemented only partially or with significant differences. Web development is full of such "standards", like HTML, CSS and "ECMAScript" where different vendors (i.e. web browsers) implement the standards differently.
The variation causes headaches, but the standardization still provides benefits. Imagine if there were no HTML standard at all and each browser used its own markup language. Likewise, imagine if there were no SQL standard and each database vendor used its own completely proprietary querying language. There would be much more vendor lock-in, and developers would have a much harder time working with more than one product.
So, no, ANSI SQL doesn't serve the same purpose as ANSI standards do in other industries. But it does serve a useful purpose nonetheless.
A few years ago, one of the worst industries as far as pipes and connectors being mutually compatible was firefighting equipment. There were literally dozens of mutually incompatible hose to pump connections. When mutual aid became commonplace among fire fighters, they had to bring along dozens of adaptors to be able to interoperate their equipment.
On September 11, both police and firefighters had private wireless networks for intercommunicating among their people. But, guess what? The two systems were not mutually compatible. So there were needless delays in communicating information from one kind of public safety servant to another.
If you go back far enough, you can find a time in New York City where about half the electric grid was DC, favored by Edison, and the other half was AC, favored by Westinghouse.
Standards sometimes come about by themselves, and are called de facto standards. More commonly, standards have to be set forth by a body specifically empowered to make it happen. As to the SQL standards, some of the largest vendors pre date the standard. In order to comply with the standard, they would have to put in engineering expense that doesn't benefit their existing client base. Worse yet, they might end up being incompatible with their own prior product.
Full compliance with the SQL standard might yet happen, but it's unlikely. Even if it does, there's a delay time between the evolution of a new SQL standard and compliance with it.
See the article "IS SQL A REAL STANDARD ANYMORE?" for a discussion about the current (2005) issues of the SQL standard.
According to the HSQLDB manual, it is the most standards compliant RDBMS.
I don't know the history of ANSI SQL specifically. But it seems that many times in software development, standards are written after the major players have already implemented their own proprietary versions of things. Once a company is invested in its own way of doing things, it's really hard to justify changing or removing features people have come to rely on just to adhere to a standard. Web standards are a primary example of this phenomenon.
Indeed, the ANSI SQL standard is not often followed. Just read SO: most SQL threads never refer to the standard while, for instance, discussions on network protocols often include the actual quote, chapter and verse of the relevant RFC.
I always suspected that one of the reasons is the fact that the SQL standard is not freely distributable. Simply getting it is not trivial. Various unofficial copies float around.)
Another reason is that it is a very complicated text and poorly organized. It uses a strange vocabulary (such as "authID" instead "user"). You need books just to understand the standard ("A guide to the SQL standard", C.J. Date, Hugh Darwen - Addison-Wesley).