"Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
news:1c68k.1012$yg7.82@[EMAIL PROTECTED]
> "David Cressey" <cressey73@[EMAIL PROTECTED]
> wrote in message
> news:QL48k.1$0f.0@[EMAIL PROTECTED]
> >
> > "Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
> > news:43_7k.979$yg7.121@[EMAIL PROTECTED]
> [ SNIP ]
> >> I agree. But it's also possible to be conscientious about educating
> >> oneself - doing lots of Googling, reading articles and books, working
> >> quality tutorials, posing questions on newsgroups - and nevertheless
miss
> >> things. Introductory material will not address intermediate and
advanced
> >> issues in detail, for example. Learning OTJ from peers and superiors
is
> > also
> >> hit and miss. And not infrequently you simply will not think to
research
> >> something because you do not know that you do not know.
> >>
> >> Take the subject of this thread, for example. *Once* you are somewhat
> > aware
> >> that there is such a database design issue, it doesn't take much
Googling
> > to
> >> turn up some good articles about it. But absent that initial
awareness
> > it's
> >> not that obvious.
> >>
> >> AHS
> >>
> >
> > The replies you gave to Gene show me how you and I can come to such
> > different views on the same subject. I learned database design in
about
> > the
> > 1984 to 1986 time frame, after programming for fifteen years. There
was
> > no
> > Google. There were no forums, (unless you count VAXnotes conferences
on
> > the Digital e-net). There were, however, a few good books on the
> > subject,
> > some good lecture series, a few very good mentors, people who taught
> > database material for a living, and most im****tantly, some examples
of
> > well
> > designed databases.
> >
> > So in my context it was very easy to become aware that there was
something
> > fundamental that I did not know, and that I needed to learn. I had
> > designed
> > indexed files before to sup****t my apps, so I wasn't starting from
ground
> > zero. And I had unconsciously applied some of the normalization rules
in
> > my
> > design of indexed files. That made it easier for me to learn the
formal
> > normalization rules and the consequences of departing from them.
> >
> > Your context sounds quite different. I don't want to put words in
your
> > mouth. I will say that there are a lot of people out there today who
> > switch
> > over from storing data in files to storing the same data in a database
> > with
> > the idea that the switch is a relatively trivial matter with a few
> > technical
> > details but no fundamentals to rethink. And the benefits they derive
from
> > using a database and a DBMS turn out to be relatively trivial, while
the
> > costs turn out to be huge.
> >
> > Some of those people learn the hard way. Some never learn. They move
> > back
> > to using files because, according to them, databases aren't worth the
> > cost
> > and aggravation.
>
> 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.
>
> I suspect the first database that I had anything serious to do with was
> likely FoxPro 2.x, which was in use at one organisation for writing an
app
> to allow people to easily define queries to retrieve end-user data sets
> (i.e. final-format data in tables that had already been through very
> rigorous conditioning and computation....this latter process being more
my
> end of things).
>
> At the time that I first started getting introduced to RDBMSs, which
> wouldn't be much over a decade ago, Google didn't exist yet either. I
don't
> recall really using any other Internet search engines back then. I
believe
I
> read a bunch of books (probably including some not so good ones), and I
> lucked out in having some fairly database-savvy bosses at my first few
> "commercial" jobs. But there's no question that my initial
self-education,
> however well-intentioned, was imperfect, and I made quite a few
mistakes.
I
> suspect what kept me interested was this: having a mathematical bent
made
> relations intuitive (and so ideas of normalization inevitably followed),
and
> I also intuitively liked the declarative paradigm...i.e. SQL core. So I
> thought it was worth pursuing.
>
> 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.
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.
Second, many of today's databases are built to be embedded in a single
application. The databases I worked on in the 80s were intended for use
by
a large and growing number of applications. For example, data from
worksations where disk were being built. It could be used for inventory
management, worker incentive management, work scheduling, assembly line
balancing, quality control , and even underlying manufacturing process
analysis, leading to improvements. There were separate applications or
tools for each of these functions, but they all shared data.
Contrast this to a contract where the client wanted some custom re****ts
written from the data in a database that was part of a purchased
application
package. When I got to hear from the lead programmer for the app vendor,
he said, quote: "There is no user useable data inside the database. If
you
want to use the data, you have to come in through the application". I
declined the contract.
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.
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.
|
