> In my not-so-humble opinion, this is a perfect example of solving
> a problem the traditional way -- which will admittedly work -- instead
> of thinking outside the box and making the problem go away. (See my
> note on the Notes->Domino fiasco.) And no, I'm not trying to pick
> on you -- it's just a handy example, and one that I happen to see a lot.
>
> A "few thousand items"? You don't *need* a database. Your data set is
> far too small to justify one. They're expensive, they eat resources,
> they're tough to interface with (if you can), they (usually) take
> training to use. And commercial ones are black boxes: you can't
> reach inside to fix it if it's broken, but instead have to wait
> for support (a bad industry-wide joke) to do it for you.
I was about to use a database for my statistics application -- several
million items that need to be processed. Then I stopped to think that for
a database, most accesses will involve three or more head seeks per
record. That means, for a single run, I would probably have some six to
ten million head seeks, if not a lot more. At that point, CPU speed is
almost irrelevant! It is faster to sort a flat file!!! (At least given
the way that process needed to access that bunch of data.)
> it probably will be in the very near future. And tying the solution
> to Moore's law guarantees you a healthy amount of scalability, even
> assuming zero improvement in the s/w or OS.
And the flat file you can scale from several million to a heck of a
lot more. So, how do you optimize? In some cases, batch similar
processes to use sorted versions of the data. In other cases, use
multiple smaller files, them merge them as needed. But if the data has to
be updated on a record basis, yes, you might find a database system is
easier to work with. Or maybe not. It just depends.
> This approach also ducks all the issues that going with a
> proprietary product raises. Most of those issues have significant
> dollar signs attached to them.
And when everything breaks down, I pipe an egrep to a file and inspect
it with an editor. Stone age compared to a database system? Well, if you
are trying to kill a lizard, a stone is cheaper and more reliable than a
bazooka! And easier on the ears as well.
And you don't have to go shopping for the bazooka, or the infantryman
either!
> It almost never occurs to the person making the statement that
> the problem *isn't* Linux/Unix, the problem is that they aren't
> considering innovative solutions and are stuck in the same-old mindset.
> They don't really need the XYZ application, they need a problem solved...
> but they've been conditioned (thanks to some exquisite marketing
> techniques) to believe the former and not consider the latter.
Problems must be defined before they are solved. Those who work in a
particular tool too often, will try to define the problem in terms of the
operations of the tool, not the needs of the end user!
Or to put it another way, the skill of creating a mental image in a
language depends more upon the speaker's ability to comprehend and
visualize, than his grasp of the subtilities of a language. You need
both, but if you are weak in the comprehension... no amount of fancy words
will help! But what do they do when they can't understand it? They
trowel on fancier words to make sure you can't understand it either!
(Doctors are the worst! I think they are taught to do this
deliberately! If my father and I didn't insist on understanding what they
tell us, why they tell us to take this or that pill, we would both have
been killed several times over! If a doctor tells you to take something,
LOOK IT UP IN The Physician's Desk Reference YOURSELF!!!)
(Oh yes, in my, um, 28 years of consulting, I have created huge
database systems for Fortune 500 corporations, modeling production of
large factories... I have programmed in at least six major database
languages that I can recall. Sometimes applications and databases are
indeed the only reasonable solution. Sometimes, they are not. The wise
person will look at how the data will be used, before going one way or the
other. And try to keep things as simple and flexible as possible.)
[EMAIL PROTECTED] ------------------ [EMAIL PROTECTED]
----------------------- IMAGINEERING --------------------------
----------------- Every mouse click, a Vote -------------------
---------- Do they vote For, or Against your pages? -----------
----- What people want: http://www.mall-net.com/se_report/ ----
---------------------------------------------------------------
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
