Slashdot Mirror

"Overall, based on elapsed time, the SSD array performed the queries 276 times faster than the ATA array. Note that this was using the 30-hour limitation on the queries. Had I waited for those long-running queries to complete, the difference may have been much greater."

"In summary, the SSD technology is not a silver bullet solution for database performance problems. If you are CPU-bound, the SSD drives may even make performance worse. You need to carefully evaluate your system to determine its wait profile and then only consider SSD technology if the majority of your wait activity is I/O related."

IBM probably did choose a cpu bound operation in order to show off their procs, but it is not the case that cpu increases will help out in all situations.

Many many many people get stuck on the fancy things the DB writers tell you SQL can do rather than thinking about the data differently. A truly classic mistake is wetting yourself over sub-queries when you're still using parent-IDs to do heirarchies.

Feh.

Parent IDs are a bad idea if you want to be able to look at multiple levels of the tree at once, especially the trees you get in threaded comments. http://www.dbazine.com/oracle/or-articles/tropashk o4 is how you do trees in SQL that obviate that. Doing it that way removes most of the need to produce recursive queries to get all the levels. Unfortunately, *most* forum software *doesn't* do it this way because such advanced data manipulation doesn't occur to them.

On changing column types, although most RDMS systems let you do it, and in many cases do so without requiring you to delete and recreate the table, a conflicting type can be a problem.

The people working on XML Query are not ignoring the history of relational databases. Heck, the language is edited by the co-inventor of SQL itself, the the Working Group chairs have been involved with (and edited) the ISO SQL spec, SQL/MM, SQLX, the JDBC and others.

= 9J =

Codd's 12 rules explain what makes an ideal RDBMS. He invented the model, so it probably makes some sense.

MySQL, in particular, violates rules #5 & 6 & 10 (and maybe more) -- it lacks a comprehensive data sublanguage (it's a subset of SQL, which already is limited in how much it can do), and views (particularly updatable views, which many RDBMS still don't support). Lack of foreign keys in MyISAM violates rule #10.

Things like views are "derived relations", and are key ways of simplifying queries. It's almost the equivalent of saying "no function names allowed" in C - everything must be in main().

Subqueries are crucial for key algebraic operations (there are 8 in total, I won't get into all of them here). One such operator is division.

Division can be simulated in MySQL using temporary tables, but this is woefully complex to specify and quite inefficient.

An scenario of a question that requires division is (excerpt from Joe Celko's article above):

A data model of Pilots, Planes, and a Hanger with planes inside of it. There's a table PilotSkills that relates which Pilots have the ability to fly a particular Plane.

CREATE TABLE PilotSkills
(pilot CHAR(15) NOT NULL,
plane CHAR(15) NOT NULL,
PRIMARY KEY (pilot, plane));

CREATE TABLE Hangar
(plane CHAR(15) NOT NULL PRIMARY KEY);

The question: which pilots can fly EVERY plane in a particular hanger?

In SQL, the answer is ugly, but requires subqueries:

SELECT DISTINCT pilot
FROM PilotSkills AS PS1
WHERE NOT EXISTS
(SELECT *
FROM Hangar
WHERE NOT EXISTS
(SELECT *
FROM PilotSkills AS PS2
WHERE (PS1.pilot = PS2.pilot)
AND (PS2.plane = Hangar.plane)));

The quickest way to explain what is happening in this query is to imagine an old World War II movie where a cocky pilot has just walked into the hangar, looked over the fleet, and announced, "There ain't no plane in this hangar that I can't fly!", which is good logic, but horrible English. (and is also why some dislike SQL.)

For more opinions to make you think:

http://www.dbazine.com/pascal9.html
http://www.dbazine.com/pascal8.html

And here, C.J. Date argues that a truly relational DBMS should be able to support an XML data type:

http://www.dbdebunk.com/lauri1.htm

(PostgreSQL is an example of a DBMS with extensible types)

For more opinions to make you think:

http://www.dbazine.com/pascal9.html
http://www.dbazine.com/pascal8.html

And here, C.J. Date argues that a truly relational DBMS should be able to support an XML data type:

http://www.dbdebunk.com/lauri1.htm

(PostgreSQL is an example of a DBMS with extensible types)

I think the advantage of voice control is *not* for PC but for a special purpose system.

Voice control is advantageous when you don't have a desk to put the keyboard on and when the system needs to handle a few simple tasks. Using biometrics it can provide a modest amount of security. (Though I'd prefer to have a smartcard.)

The real reason it hasn't caught on is that there's still no good way of integrating these appliances with PCs. I'm pessimistic about that because XML is actually a step backwards.

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.