"David Cressey" <cressey73@[EMAIL PROTECTED]
> wrote in message
news:RTs8k.62$%b.24@[EMAIL PROTECTED]
>
> "Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
> news:Wtk8k.133$1o6.120@[EMAIL PROTECTED]
>> 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.
>>
>
> You are right. I still use flat files on occasion, and I use CSV files
as
> well. I also still tune in to AM radio on occasion. Our entire legacy
> deserves respect. The people who went before us were just as smart as
we
> are, and some of them were even smarter.
>
> I partly disagree with your *****sment about people who don't "get"
> databases. There are people who don't "get" query optimization or
> concurrency management, or transaction isolation, but who work just fine
> in
> a single user files environment. To me the question is more like: do
they
> or do they not "get" data? There are a lot of programmers who just
don't
> think that there is anything to "get" about data. These people tend to
> think that a computer program is a bunch of tedious garbage, followed by
> the words "procedure division" or "begin" or some such introduction to
> "the
> real computer program".
>
> Unfortunately, the object oriented paradigm has taught many people that
> data is a bunch of details that are best hidden away where almost no one
> can
> see them. In the context of object oriented programming, that is a
> valuable truth. In the context of data managment, it's the worst
possible
> attitude.
Not "getting" data is part of a larger problem, which is forgetting what
software is actually for. Most end users couldn't care less about how
their
solution is implemented, they just want a useable program. Useable meaning
reliable, not too hard to use, reasonably fast and so forth. Not "getting"
data is also accompanied by not "getting" user interfaces, re****ting
requirements, do***entation, error recovery etc.
One job I worked at involved property management software. We didn't write
the stuff, we had to access the backend data for the various applications
in
use. Some apps used databases, some used files. Let's just say that on a
scale of 1 to 10 not many of these programs rose above a 5 on any
objective
criterion. The treatment of data was often particularly bad. As an
example,
how can you have a system that has as one of its main purposes the
management of rental information, that only provides for the entry of
personal information about one tenant? Guess how the typical landlord or
property manager is going to store information about two or three people?
That's right, any way that works...like stuffing three last names into a
single surname field. One application at least anticipated that there
might
be multiple tenants - they provided six separate fields to account for the
first and last names of up to 3 people...not exactly a stellar solution.
And
these apps often featured what I call "just in case" columns in their
tables, columns labelled like Info1, Info2, Info3 or suchlike, not
infrequently exposed to the end user, and not surprisingly used by the end
user in very personalized ways to store data. In other words, dangling
data
as far as standard (anticipated) retrieval was concerned.
This wasn't a failure of "getting" data - this was a failure to "get"
practically anything.
A lot of programmers don't "get" any of this because they are too focused
on
the implementation details, and not enough on what the actual purpose of
the
software is. Every programmer should have to work at least once directly
for
an end user who just wants results, and doesn't care about the details of
how it's done. In real life not many programmers ever are answerable to a
client. And I mean answerable to a real end-user, not an internal
end-user.
The kind of end-user that will look at your new app running on a Pocket
PC,
and say "it's a pretty interface, and my IT manager tells me you guys have
done a nice job of integrating your server side with our ERP system, but
you
know, my drivers will never use this".
>> 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.
>
> I agree with your point. But I reiterate that there are some people
who
> will be more productive with files in an environment where you or I
would
> be
> more productive using a DBMS.
That's very likely true. You mentioned a crossover point before, and this
is
of course a personal crossover point. But I think we'd both agree that
there
are objective criteria also for when a file approach is indicated, and
when
a DBMS is indicated.
AHS
|
