Jean-David Beyer schrieb:
Quote:
Looks like you've been reading about NoSQL.
I thought you were trying to be funny, but I see NoSQL actually exists.
To the extent to which I understand it after glancing at their first web
page, it provides an SQL interface to the UNIX file system, using normal
UNIX tools. A triumph of something or other.
IMO the idea of using a common interface (maybe SQL or anything else) to
retrieve information from any collection of informations is a very
common IS principle. As soon as some "driver" can extract certain common
properties from any collection (be file systems, text, pictures...), it
can establish a connection to a general query/retrieval system.
Quote:
But of course the main benefits for a dbms is not the fancy interface,
even if it is pretty much standard these days, but the same thing that
is a reason for the increases in productivity when using proper
programming methods in whatever language you choose to employ:
Separation of Concerns, and Information Hiding.
In the 1970s where I worked, people just did not get that. They said
they could always use less disk space and a little less time by using
UNIX flat files. And of course, that is usually true. But the instant
someone needs to make a change in the data structure (e.g., adding a
column to a table, changing a field size, changing the internal
representation, changing the indexing to accommodate new usage
patterns), or add transaction processing, all the programs using the
database have to be re-written, rebuilt, and integration tested again.
Such a databse is *designed* for an specific use case, and fast access
to indiviual predefined elements. When I tried to unify and automate an
catalog of my program CDs in the 80th, including program descriptions
and access (installation...) information, I had to deal with many
different CD formats. Nowadays I have the same problem with my movie
archive, or with compressed file archives (tarballs, RPM, DEB...) of any
kind. While at that time a collection of CDs only could be used as an
offline archive, nowadays the data sources could be made available
online, and the unified information can be retrieved by dedicated driver
objects, for every data source made available. This model is not
optimized for fast access, instead it is optimized for little
maintenance overhead. As soon as a new "driver" class is added to the
retrieval system, the "database" is extended by all information that can
be delivered by that driver.
Nowadays "data mining" has a similar goal, i.e. to extract informations
from data sources, which had not been put *intenionally* into databases,
in a predefined record format.
Quote:
And on real projects, the changes to the database never stop; even when
the salesmen say the requirements and design are frozen, they are not.
So more time is spent redesigning the existing programs, trying to fit
new programs in on an ever-changing foundation, than anything else. I
have seen cases where entire projects were scrapped because they could
not keep up with all the changes.
A relational dbms can deal with all that. Flat files cannot in any
practical application in the real world. A dbms is much more than a
fancy programmer or user interface and some clever indexing. That is
what shows, but is not even the most important part.
A DBMS only can *help* in the process of structuring information, in a
rigidly restricted data model. Like when you write structured code
instead of spaghetti code. Flat files, may be binary, textual, or XML,
can be designed for easy extension by updates to the access methods,
without a complete reorganization of the entire database, as frequently
is required when a "closed" DBMS with a hard coded record/table/index
structure is used.
DoDi
SitemapIndex
RSS Feed
0x61.com 2009-2010 - Internet Forums and much more!