At 01:24 PM 7/13/2003 +0300, Antonios Christofides wrote:
>Whether my idea about the tree is good or not, it is true that the
>application initially has its data in some data structures suitable for
>computers rather than humans; it converts them to SQL, which is suitable
>for humans, only so that the SQL will be converted back to structures
>suitable for computers. The most obvious example is that integers are
>converted to decimal by the application only to be converted back to
>binary by the RDBMS.
>
>I understand that SQL is the interface between apps and RDBMS's because
>of history, not because it is correct design. Could you point me to a
>link or book or paper that deals with this paradox? Thanks!
Often one man's impedance mismatch is another man's layer of abstraction.
An integer in the app is often not the same thing as an integer in the
database. Have fun when it comes to dates and times.
As SQL is a somewhat human readable/writable API, people can leverage[1]
tons of different tools to use or abuse it. And that's what has been done.
I daresay if someone came up with an ultra-elegant mathematical efficient
DB interface, only a few geniuses would actually read the thesis,
understand it and use it.
Also in most cases I've seen on this list, the bottlenecks are elsewhere
(e.g. I/O, wrong plan, query, db schema) so this sort of thing might be an
unnecessary optimization.
HTH,
Link.
[1] OK so I used the L word.