"David Cressey" <cressey73@[EMAIL PROTECTED]
> wrote in message
news:T678k.6$%b.5@[EMAIL PROTECTED]
>
> "Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
> news:1c68k.1012$yg7.82@[EMAIL PROTECTED]
SNIP ]
>> Nicely phrased, and you're quite correct, my context is not the same as
>> yours. My initial background is not databases at all - it's data
>> files...potentially reams and reams of them. Think scientific
programming
>> back in the late '70's, '80's and early '90's and you'll have a good
idea
> of
>> my initial computing environment. The typical data file would be
>> individually well-described and well-structured, both text and binary,
>> but
>> there really wasn't a strong argument for using databases. netCDF is a
> good
>> example of the kind of system that a scientific data shop would use.
>> There
>> is a lot of discipline, no less so than in a good RDBMS-oriented place,
> but
>> one does not think quite the same way.
>>
[ SNIP ]
>> Certainly my comments are phrased against the above background.
>>
>> I might add, with respect to some of your final comments, that I'm not
so
>> sure I'd want people who give up on using RDBMSs to switch back to
files.
>> Because proper use of files is not a trivial matter. To put in a recent
>> timeframe, would _you_ want a person who can't get SQL and normalized
> tables
>> and indices to switch over to XML and XSLT? :-)
>>
>> AHS
>
> I did a little scientific programming myself back in the 70s. Actually,
> it
> was engineering oriented business programming. For example, I had to
> modify a program written to keep track of the "inventory" for a company
> that
> ran a natural gas pipeline that was about 200 miles long, and fed about
> two
> dozen retailers. "Inventory management" of a product like natural gas
is
> more like scientific work than commercial work, even though the purpose
> was
> commerce. At that time, I had no database background either.
Traditional
> inventory management involves counting things. This kind of inventory
> management involved thermodynamic formulae.
>
> I once heard someone say that scientific programming involves very
> sophisticated processing of fairly simple data, while commercial
> programming involves fairly simple processing of righly structured data.
> It's an oversimplification, but there's some truth in it.
Yes, there is a fair bit of truth to that. Look at physical oceanography,
for instance. You get a huge amount of mileage out of nothing more than
time/position readings of temperature and salinity.
> My "conversion" to database work took place at the same time as my
> switchover to business oriented information systems. To me, it was the
> beginning of a second career.
>
> As far as telling some people to stick to files, that's not as snide as
> it
> might sound. In the first place, there is actually some work that
> *should*
> be done in XML. (I don't know any XSLT, but I presume the authors of it
> are
> not total fools.) Some of my fellow experts disagree with me on this
> score,
> but that's my story and I'm sticking to it.
I'm absolutely not knocking XML. I happen to think it's overused, but it
is
a natural fit for many applications.
My actual point was, flat files deserve respect also. The attitude I was
thinking of is exemplified by a poster in another newsgroup, who had to
process legacy flat files produced by what the fellow referred to as "old
programmers who only know Fortran", or something like that. What he was
actually having a problem with was header lines. I figure, if a programmer
doesn't have the discipline or willingness to "get" databases, they won't
be
so hot with regular files either.
I'd also be a bit dubious about such a programmer tackling binary data
files...
[ SNIP ]
> Today, creating a new database has become so easy that many programmers
> use
> a DBMS to manage data in almost exactly the same way they would use a
file
> system to manage data. I'm not being facetious when I suggest that some
> of
> those people would get more productivity out of files.
I suspect you're right. I'd phrase it differently: depending on the
application any one of us might get more productivity out of files.
Another
factor is this - a huge amount of the productivity associated with files
derives from skillful use of shell programs like awk, cut, paste, grep etc
etc, and the percentage of programmers that are dab hands with tools like
this is not great.
> Ultimately data sharing and data management on an enterprise wide scale
> is
> more productive is you learn a good RDBMS, database programming,
> database
> design, data modeling, and data analysis. I don't know where the
> crossover
> point is from where the shorter learning curve for files and the greater
> potential for databases balance each other.
Very interesting question. And then there is the question of how do you
classify things like Berkeley DB?
AHS
|
