From: JG
To: Editor
Date: July 28,2003
I saw this exchange on your site On Look, Ma, XML, No
Database Design! about the following quote from Oracle's XML DB
documentation:
"Storage Independence: When you use relational design, you
client programs need to know where your data is stored, and in what format,
what table, and what the relationships are between those tables. XML Schema
allows you to write applications without that knowledge, and allow the DBA to
map structured data to physical table and column storage."
Recently I wrote a couple articles about XML DB, and I too
saw this quote and was bemused by it. It's important to bear in mind though,
that this passage was written from an XML-centric point-of-view.
This quote is bemusing, because it calls to mind one of the justifications for
relational databases: that programmers no longer need to worry about where and
how their data was physically stored. This is the same thing come 'round again, but on a different
level. Whereas COBOL programmers needed to map their data into files, and
relational databases freed them from worrying about files, XML programmers
often need to map their hierarchical data onto relational tables, and XML
Schema frees *them* from worrying about that mapping.
It occasionally seems to me that the computing industry moves in cycles,
solving the same problems over and over again, but at different levels of
abstraction. This strikes me as one example of such a cycle.
Oracle is not declaring their database to be obsolete, as TH suggests in his
email to you. The passage in the manual makes perfect sense once you realize
the target audience consists of XML programmers. I admit though, that the manual writer's choice of
words here is rather humorous and initially confusing.
From: Fabian Pascal
To: JG
Practitioners today in general and XML people in particular,
do not learn any fundamentals, they are self-taught on products only, so there
is no way for them to know and understand what's behind technologies and
products, it's all marketing crap.
From: JG
Thinking back, I began with products myself, and even now I'm
not so sure I'm strong in the fundamentals. In many cases I've probably backed
into the fundamentals, having learned product specifics first only to later come back and learn how those product specifics fit into the overall fundamental puzzle. I'm not entirely
certain that's a bad approach. Children learn specifics first and generalities later, why not
adults?
You know, I should tell you a story about my first book on SQL and databases,
which was perhaps only my second computer book purchase ever. It was Date's
"A Guide to the SQL Standard", the first edition. I first saw it in a bookstore in the Saginaw Mall while working for Dow Chemical. I can still picture in my mind where I was
standing. The book looked really good, but I couldn't convince myself to part
with $35.00 for a book that was less than 1/4-inch thick. So after a fair bit
of bureaucratic rigmarole, I got Dow to buy it for me. What a cheapskate I was!
Well, I must tell you that Date's little book had a HUGE impact on me,
especially the appendix in which he discussed all the various things he didn't
like about SQL. That little book put me head-and-shoulders above everyone else in my department when it came to working with relational databases. I became the go-to guy for DEC's
Rdb, and I fell in love, so-to-speak, with SQL and relational technology.
Eventually Dow laid me off, and I left that first-edition behind when I vacated
my office--something I kick myself about to this day. (I was too honest to take
it, because it was "the company's") I've bought every subsequent
edition though.
So next time you see C.J. Date, please tell him his little book is one of the
key things I look back on as having propelled me down the road to a career
working with (and now writing about) databases. It was probably the most money I ever paid per-page
for a computer book, and yet I probably got the greatest value in return.
And by extension, if I ever write an article and Date doesn't like it, well,
it's his fault <grin> for having got me started.
So if I were going to write one article on fundamentals for Oracle DBAs and/or
Oracle programmers, what would it be about? What fundamentals are we lacking?
From: Fabian Pascal
I can spend about half an hour explaining why it's a bad
idea. Children learn by trial and error and that's a very inefficient way for
adults. Besides, very few fall back like you on fundamentals, there's no demand
for it in this society and they're not even aware there's anything like that.
And thinking is hard, if it's not instilled in you, which is on purpose.
Not entirely your fault. You are a product of this society
and this is what it socializes you to. Intentionally.
Good for you, but in most cases that does not work. You
normally would be marginalized for trying to do things right. After all, that's
all theoretical stuff and they have practical things to do.
I will forward your message to Chris.
That's what the website, papers, books and seminars are
about--you want it by email? Are you still cheap? :).
Go through the weekly quotes and see if they make you cry or laugh; if not, you
lack the fundamentals.
Ask yourself, can you precisely define a database? A DBMS? Data
independence? The Information Principle? Closure? And so on.
Posted:
10/03/03
[ABOUT]
[QUOTES]
[LINKS]
