SPUG:CGI header question

[Aaron Salo]

At 09:56 AM 6/19/2003 -0700, Peter Darley wrote:
>	A partial rebuttal :)

Much appreciated. I am open-minded to changing my opinion, just have never
heard a compelling argument to do so. Let the discussion begin!
<g>

>		I want to have central data storage, meaning a single machine that servers
>all the data/files/etc.  If I store stuff in the database I don't have to
>mess with other paths of data from my central storage to the web server(s).
>It may be easy to set up a nfs share or whatever (which isn't actually the
>case), but then I need to maintain twice as many services on the server,
>secure twice as many access points, and rely on systems that are harder to
>secure (NFS vs. database access).

Understood, hypothetically, but in the instance we're talking about I'm
having trouble getting traction here. The only way you could gain a benefit
from this would be to eliminate the file system based content entirely,
thereby removing the need for a place to store files completely.  We are
talking about a web application, right? Are you also going to store all
HTML static content in the database as CLOBs? What about your CGI scripts?
Probably not unless you are the most awesome mod_rewrite god of all times
and you're dynamically generating your perl scripts from database calls and
mod_rewrite skullduggery of Damianesque proportions. That stuff is in a
filesystem. So by definition you already have a filesystem and a database. 

Even in a load balanced distributed front end system with a central
database, you either have a central place for your static content to reside
(NFS) or you're replicating it out to each of the front end systems from a
staging server. Either way you have content in a filesystem already.
Putting the images into the filesystem where they can be served up by
apache along with the HTML and other static content is no stretch, and no
increase in services or security concerns beyond the status quo. The only
exception would be if you had a fully database driven system with ALL
content in the database and NO content in a file system, and that is highly
unlikely. Even fully dynamic CMS systems have content in file systems, even
if that content consists of templates. 

>		When performing backups I only have one thing to back up; the database.
>If data is stored in the FS and in the DB I have to back up both and it gets
>to be significantly more work backup and restore.

Not sure I agree with you here, given the fact that if you're a prudent
sort you're backing up your filesystem and your database anyhow, your
server has files on it you're already backing up. I hope. If you need to
restore, because you had disk failure and you need to get some missing
files, do you want to go through the entire database volume and find your
restore point to get those blobs back, or do you want to granularly (word?)
untar the missing files out of the filesystem backup?

>		I don't have to have extra functions/etc to work with/delete/whatever
>data.  I can treat all data the same and have the same functions for working
>with them.  There's nothing about binary data that is magically different
>from other data, so why have a whole second system to work with it?

Actually, depending on your database, there are some arcane and proprietary
ops you need to do to work with blobs in a general sense. Let's skip that
for now.

I don't
>know a lot about files systems, but it's my understanding that you are
>limited to the number of files in a single directory.  I do know a lot about
>databases however, and I know that there's no problem storing millions and
>millions of records in a single table.  If I exceeded the limits of the file
>system in a single directory I then have to start making trees of
>directories to hold all my files, which makes for a huge mess.  I currently
>have directories for a system I wrote that didn't store stuff in the
>database, and I can't go into the directory and do a 'rm -rf *' because
>there are more files than rm can deal with.

I'll presume that you are being the devil's advocate here and have your
tongue firmly in cheek.

>		In general databases are far easier to work with.  That's why people talk
>about 'making the file system work like a database' and never talk about
>'making a database work like the file system'.

I have a hammer and a screwdriver. The reason why is that they are suited
to different tasks. Although I have occasionally used the handle of a
screwdriver to pound in a nail, or used the blade to pry one out, the
hammer is best suited to those jobs. I don't remember ever wishing that I
had a "hammer that worked like a screwdriver". That's why I have both.