RE: Death of the database

While I agree with the article about inventory control and health records they authors ignore a big slice of what a database is for. In the supermarket example, the supermarket and the vendors want to know historicly how long that can of soup sat on the shelf or how long it was at each stage of manufacturing and in shipping etc. Are they saying we need to send an RFID read pulse and a GPS out to find the cans of tomato soup throughout the world? For planning purposes larger than a can you need to track the movement of the things. The historic "cache" is important. So if a customer calls in to a call center do we encode that information into the EMR chip (electronic medical record) on their hand or is that encoded into the electronic chip embeded in the customer's walls? Silly. Should each Intel processor carry around its 100 megs of information Intel needs to store about the historic steps to produce it? That might make it a little dicey at retrieving the information for studying effects of changing how a chip is produced.  

The authors took a very small slice where this makes sense and then used that to declare everything is a nail. In the whole database industry maybe this is applicable to .05% ignoring the technology limitations. Jim

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Gogala, Mladen Sent: Monday, October 24, 2005 8:34 AM
To: 'jkstill_at_gmail.com'; Oracle-L Freelists Subject: RE: Death of the database

Jared, it's not the end of the database and it is neither beginning nor the end of idiotic magazine

and web articles. Commentators like that are a very important reason for keeping capital punishment

in the legal toolbox. This commentator probably wants fair and balanced look at the data but without

all those pesky structures that he would have to learn about. The article itself contains some misconceptions

about the data:  

"The premise of Gartner's argument is that as improvements in networking technologies eventually lead to real-time connectivity to any data, that that data is best kept closest to its natural source rather than at the intersection of a row and tuple of a database that, as it turns out, is actually little more than a remote cache. "
 

To my knowledge, one doesn't "connect to any data", one uses the data. One connects to program that manages data.

There are various data management programs, some of them even implement part of what is known as "naïve set theory",

without the axiom of choice, Zorn's lemma and well ordering theorem (forgive me for this gobbledygook). Their role is

to impose tabular data structure on the data as well as to enforce business rules for the data and to optimize data retrieval

from application to application. That is quite different from being a simple cache. Gartner's statement would hold water if

we re-work it a little, like this:  

"The premise of Gartner's argument is that as improvements in networking technologies eventually lead to real-time connectivity to any idiot

claiming to be an analyst,. It turns out that idiots that idiots are best kept closest to their natural source, like Gartner rather then having

them in the real world commercial environment. It redefines the role of Gartner as a remote cache of idiots."  

Now that is something that I believe we all can agree with.  

--

Mladen Gogala

Ext. 121

________________________________

From: Jared Still [mailto:jkstill_at_gmail.com] 
Sent: Monday, October 24, 2005 10:40 AM
To: Oracle-L Freelists
Subject: Death of the database

 


Anyone seen their workload reduced due to unstructured data?

Death of the database

As improvements in networking technologies lead to real-time 
connectivity to any data, that data will be best kept closest 
to its natural source rather than at the intersection of a 
database's row and tuple. At last week's Symposium ITxpo, Gartner 
analysts backed up that premise with two examples: an RFID-tag 
equipped can of soup, and a chip embedded in the back of a human 
hand. Must data always be stored -- or cached -- in a database? 
If not, it's time for DBAs and BI vendors to to reinvent themselves.
http://ct.zdnet.com.com/clicks?c=625728-4778725&brand=zdnet&ds=5&fs=0


-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist


--
http://www.freelists.org/webpage/oracle-l