It is unfortunate this page helps perpetuate myths and misinformation about databases.
For example:
It says there are RDBMSes in the market today. There is only one, Alphora Dataphor. All the others are SQL DBMSes, and SQL violates too many fundamentals of the relational model to be called a relational language. Therefore, SQL DBMSes aren't RDBMSes.
As a consequence, it says RDBMSes are slow. SQL DBMSes are slow, but RDBMSes needn't be, as the relational model defines that the physical model can be quite different than the logical model of the database. Thus, one can keep a clean logical model yet implement all kinds of optimisations in the physical level. That is what SQL optimisers try to do, but due to SQL complexity and confusion of the logical and physical model they fail.
-- Leandro Guimarães Faria Corcete Dutra, May 18, 2004
I agree with the above poster in that the author is confusing SQL DBMS or a relational database. However I can forgive the author for this because this is so common in the industry (even if he is from MIT).The slowness of most databases while inserting is because most database systems force the data to disk after each insert. This is a safety 'feature' not a performance 'bug' and has nothing to do with performance. Simply wrapping the entire load process in a trasaction should have fixed the problem.
The Author's comments about PostgreSQL not being scalable is commercial systems are incorrect. PostgreSQL implemented write-ahead-logging (which is what he is talking about) with version 7.2 in 2002. Also, PostgreSQL has MVCC which makes it very, very scabale...some commerical implementations do not even have this, for example MS SQL server.
Merlin
-- Merlin Moncure, March 18, 2005
Phil is somewhat incorrect about vendors supporting row-level locking support. MS has supported row-level locking since SQL Server 7.0. In practice, its transaction manager decides how granular a lock will be according to the parameters of the query. If too many individual rows are going to be locked in a transaction (according to some calculated "lock escalation threshold"), the entire table will be locked.
-- pete lai, June 8, 2005
It is just terribly wrong to recommend MS Access database for any internet website, server-side or backoffice use. [1] Extract from: "INFO: Considerations for Server-Side Automation of Office" http://support.microsoft.com/kb/257757/EN-US/ "Current licensing guidelines prevent Office Applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA)." My 2 coins. Guennadi Vanine
-- Guennadi Vanine, July 10, 2005
The reference to MySQL is very out of date. It seems that most people's understanding of MySQL's capabilities is mired in MySQL 3.x. Philip mentions that his information is current "circa 2003" but quite a lot has changed since then. For OLTP and enterprise grade applications, the stable now includes:MySQL 4.0, with InnoDB ACID-compliant storage engine MySQL 5.0, with InnoDB and standards compliant stored procedures, triggers, views, etc. MaxDB, formerly SAP DB, "a heavy-duty, SAP-certified open source database for OLTP and OLAP usage". (Those who follow such things will note that Oracle now owns Innobase Oy. However MySQL's license to sell InnoDB has been renewed. They have several other OLTP options in the works, including a recent announcement of partnership with Solid Information Technology.)
-- Toby Thain, April 17, 2006