databases: storing pages in / web front ends to

   Date: Thu, 18 Jan 1996 14:30:10 +0100 (MET)
   From: Robin Stephenson <>

     My short-term aim (read: next month or so) is to identify some way
   of putting Web pages into a database as objects, and having an object
   server sitting inbetween our httpd and the database files.  Ideally
   I'd have some way of ensuring (or at least checking) link integrity,
   etc.  The appeal of this solution to me is that it is scaleable, and
   in the long term I may have to manage thousands of Web pages, rather
   than the few dozen I do at the moment.

Gee, do you actually want to put regular HTML pages into a database as
objects, even if they just contain static text?  I've been asking
people about this, and haven't heard much interest in it, so I'm
curious what you feel would be the benefits ot such an approach.

For checking link integrity, I've mostly been hearing about various
Web-site-developer tools that are supposed to do this for you.  I get
the impression that they're kind of "batch" oriented, i.e. they go
over your whole site and check out all the within-site links.  I think
WebStar (is that the right name?  The O'Reilly web server that's sold
in a box) comes witha tool like this, and Vermeer has one, and Adobe
SiteMill is another.

What scaling problems are you anticipating?  I get the impression that
there are a lot of web sites with thousands of pages that are just
stored as ordinary files.  I guess checking links in "batch" mode
could cause one scalability problem (it would just take too long to
run it).  Were you thinking of anything else?

I'm interested in this because we (Object Design) make an
object-oriented database system (called ObjectStore) and I'm trying to
learn more about the suitability of our product for the kind of
purposes you're talking about.

     Another thing that I'd like to be able to do is implement a Web
   front-end to a transaction-processing database - e.g. write a simple
   script to get information from a form, tell the database it's a
   payment, or a debit, and have the database do most of the work (then I
   can get on with writing nice Web pages, and leave Perl more-or-less
   alone...)  It seems to make sense to me to implement both database
   systems on a common platform, or at least with a common interface.

If you're just talking about using a conventional RDBMS, there are
quite a lot of products out there to help make this easier.  There's
net.Forms from net.Genesis, and Cold Fusion from Allaire, and IBM's
DB2-WWW Connection, and others.

Received on Thursday, 18 January 1996 11:24:47 UTC