So in your opinion, is the problemWell, as far as we MV'ers are concerned, performance IS a problem with the relational approach. The attitude (as far as I can tell) with relational is to hide the actual DB implementation from the programmers. So it is a design "flaw" that it is extremely easy for a programmer to do something stupid. And you need a DBA to try and protect the database from the programmers!
As soon as a requirement for a database specifies extraction of the maximum power from the box, it OUGHT to rule out all the current relational databases. MV flattens it for it for performance. As an MV programmer, I *KNOW* that I can find any thing I'm looking for (or find out it doesn't exist) with just ONE disk seek. A relational programmer has to ask the db "does this exist" and hope the db is optimised to be able to return the result quickly. To quote the Pick FAQ "SQL optimises the easy task of finding stuff in memory. Pick optimises the hard task of getting it into memory in the first place".
1) SQL is so hard that the average programmer will not know how to use it efficiently or 2) Relational (or SQL-) DBMS'es are just too slow
If 2) then why don't we get a bit more concrete. Could you give an example of a query that in your experience would be too slow using a standard SQL database (e.g. Oracle, or MySQL). We could then actually try it out on some machine and compare. I suggest using the customer-order-order_detail-product database
If 1) I would like to hear some concrete examples.
best regards, Lauri Pietarinen
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
