keith said:
>   This wisdom is absolutely a must!

sigh.

keith, you're a perfect exemplar of the technocrats
that i was just talking about...  and making fun of...

they saw lots and lots and lots of cases where someone
used the file-system as a database and then ended up
having problems with scaling when it eventually grew.

so those technocrats then came to believe that they'd
seized upon something "inevitable", so they started to
enforce the iron-clad rule that "you must _never_ use
your file-system as a database, because it won't scale".
and they're proud of themselves, and puff their chests,
and slap themselves on the back for this bankable info.
furthermore, they repeat the mantra to each other often,
confident that they've come across some ultimate truth...

the problem is, there are some exceptions.

and this is one of them.

as long as you have a script working on only one book,
consisting of just a few hundred page-scan images and
a few hundred corresponding text-files, and _further_,
you have _no_more_ than a dozen people working on it
(if that, and usually not simultaneously), then you are
_not_ going to have any "scaling" issues with that script,
especially if 80% of the text-files will never be changed.
(and none of the graphics files will ever change, save for
occasional swapping-out of some badly-imaged pages,
which isn't even something that the script will manage.)
and even if you have a team of a dozen people working
simultaneously on a book, they'll finish in half-an-hour.

so you are _not_ going to have any problems with "load".

and the important thing is that we _know_, for _certain_,
that the per-book task will _never_ exceed beyond that...
so we will never be taken "by surprise" by scaling issues.

we might gain a ton of users, and eventually be working
on thousands of books at the same time, but _each_book_
will still be a very small bite, easily chewed and swallowed.

more users would mean more hardware, and bandwidth,
and more copies of the script running in different folders,
but each script is still going to be doing a very easy task...

that is why this particular usage is _an_exception_ to the
rule that you shouldn't use the file-system as a database.

so your "advice" is wrong, keith.  it's just flat-out wrong.

and i was watching closely as roger developed his system.
so i saw him make the error as he was in the process of it,
and i saw the ramifications of the error...  all of a sudden,
things were squirreled away in a database, thus opaque...
in this type of workflow, you want content out in the open.

and equally important here is the point that roger needs
to know that he _can_ mount a full-on site, if he _wants_.
he's now suffering from the misimpression that he can't.
maybe he doesn't _want_ to do that, that i'd understand,
but i don't want him to think he can't, when really he can.


>   What most do not understand that in order to have
>   a "proper" database for any non-trivial task, you
>   must add layers of abstraction in order to administer
>   all transactions and function needed. Without them
>   a system will eventually bog down and will not scale well.

this is the other sickness that technocrats have.

first they introduce complexity.  then, when the complexity
starts to make it difficult to handle a very simple situation,
they add _more_ complexity, as if that's gonna solve it all...

and _that_ is what causes things to "eventually bog down"...

-bowerbird