August 12th, 2002, 09:59 AM
How SQL Works (very technical)
My boss gave me an assignment to find out how SQL works - he is looking for a very technically detailed explanation.
The explanation has to do with 'sets' and 'trees' etc.
I have been searching the net and books, but they do not go into enough detail concerning this.
I think that the explanation my boss wants, is so technical that it is beyond the scope of most books and sites concerning SQL.
Can anyone point me in the right direction?
August 12th, 2002, 10:24 PM
What does he want to know? Why?
August 13th, 2002, 01:54 PM
The explanation has to do with 'sets' and 'trees' etc
He wants the technical reason why it is faster than flat files, not the conceptional reasons.
I thought the answer to his question was obvious, considering usage of tables, indexes, etc., but he is looking for another type of answer.
He wants me to have a complete, technical understanding, but he wants me to find the answer.
August 13th, 2002, 02:58 PM
Yes, most SQL books don't explain why, or what is behind the syntax, but merely give you 'cookbook' approaches to standard problems.
Spend some time at www.dbdebunk.com, and if possible, purchase some books by Chris Date. (Chris (or C.J.) Date is one of the original researchers who developed the relational data theory, along with E.F. Codd, back in the 1970s). At www.dbdebunk.com, Date and a couple others discuss many things about sets, trees, substitutability, etc... and much more info can be found in their books. We had a discussion about some of this the forum a few months ago in The Future of RDBMS.
Unfortunately you must be prepared to find out that these researchers believe SQL was a bad decision from the first, because it doesn't fully implement the possibilities of relational algebra. In fact, there has been virtually no company with guts enough to take this step, with the possible exception of Alphora, with their product called Dataphor. I am going to be evaluating it soon, so I will provide some more information here in the forums, in the next few weeks. I sincerely hope that Dataphor is everything the Alphora people claim, because it is high time the software industry had something better than SQL.
Also, there are many software companies trying to sell 'alternative' solutions to SQL, which usually involve some sort of "Object oriented", "Multivalued", "Post-relational", "XML-based" system. The problem with most of these is that they are usually tied to a particular application framework, such as Java, and they don't fully implement the relational paradigm. This means they can do trees quite well, which is SQL's weak point, but they are not so good for many other generalized operations involving sets, normalization, views, etc...
Good luck; you have a lot of serious reading ahead of you .
August 13th, 2002, 03:33 PM
An obvious reason is for example that DMBSs store data in B-trees which allow for faster searching than unstructured 'flat' storing in worst cases as well as in average cases.
The worst case for finding a certain entry in n entries stored flat is obviously n tries (if the last entry has been the desired one) where a binary tree grants a worst case of log(n).
Also a flat file system will probably not provide SQL querying which is a conceptual thing, though.
For the tree stuff... that's computer science 2nd semester, maybe you'll find more in books like
August 14th, 2002, 09:22 AM
.....Thank you both for the help