In article <46ubt5$e...@gordon.enea.se>,
Erland Sommarskog <som...@enea.se> wrote:
> [ musings about using a RDBMS instead of a file system for news ]
There's a lot of similar technology and parallels between DBMS and file
systems. For instance, there are file systems out there which use B-trees
to store meta-info such as directory entries and block maps. There are
many filesystems which use a transaction journal.
It appears that no one has yet felt the shortcomings of using the UNIX
filesystem as an article database is worth the effort of building a better
system. However, news implementations on systems providing particularly
pathetic filesystems (MS-DOS) have to provide some sort of "database" or
"user space filesystem" in order to provide reasonable features and levels
It would almost certainly be easier to provide a SQL interface to the
current article database than it would be to develop a new storage
If said SQL interface made usage of the indexed history file and .overview
files, you'd probably have a real interesting tool. Toss in an article
word index and we'd have almost everything we need for extemely quick virtual
newsgroup newsreaders or automated scoring efforts.
True, but as I pointed out in my previous article, using an RDBMS for
storage would severely reduce the number of potential installations -
even if you manage to write a system that is not restricted to a
certain brand of RDMBS.
On other platforms the situation is slighlty different. On NT you
you could probably rely on the precence of ODBC. (The assumption
is here that most NT boxes has an RDBMS close by, while many Unix
machines haven't one in sight for miles.)
I recall that I and Terry Poot several years ago discussed the
possibility of using Rdb on VMS, which made sense at the time,
since DEC for some time shipped Rdb runtime with VMS. (I believe
they later made Rdb runtime a separate license again.) Terry was
the enthusiastic, and I was the skeptic. I've never played with
ANU-News, but I gather it is far less reliable than INN, then
again it does not use plain files as I believed at the time.
Anyway, even if one had relied on the Rdb runtime being present,
the maintenance for system managers without any other RDBMS would
probably have been even more of a headache.
>It would almost certainly be easier to provide a SQL interface to the
>current article database than it would be to develop a new storage
Now wait, are you telling that it is easier to write an SQL parser
and optimizer to operate on a bunch of text files spread over ten
thousands of directories, than to a write a news transsport system
that were to use an existing RDBMS engine?
Or are you talking about writing your own SQL database? In the latter
case, I certainly don't disbelieve you.
Hm, when I think of it writing this RDBMS-based news transport is
not such a bad idea, after all. Not that it would be very useful,
but it sounds like interesting research.
Erland Sommarskog, som...@enea.se, Stockholm