Date: Tue, 31 Mar 1998 08:39:41 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: nik@iii.co.uk Cc: freebsd-database@FreeBSD.ORG Subject: Re: Mailing list search interface Message-ID: <XFMail.980331083941.shimon@simon-shapiro.org> In-Reply-To: <19980331134928.03855@iii.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31-Mar-98 nik@iii.co.uk wrote:
...
> I'm probably going to shut up in a second, because this is starting to
> get out of my depth.
Nah. Your input IS valuable.
> It certainly looks like Wolfram and co. have been making a number of
> changes to the list archive software to make it more useful (and as John
> says, things like MHonArc and Glimpse will not scale well, although
> they're fine for my current problem)
There are several issues for you to consider:
a. Scalability; Rarely linear. Typically exponentialy degrading. A
solution that is lighrning fast, economical and alltogether wonderful at
one scale will fail miserably at another.
b. Personal Taste; Some people love Oracle, some hate it. Some love
Infomrix, some hate it. No way around that one. arguing and
demonstrating can help, sometimes.
c. Familiarity; Most Unix types are very familiar with text processing.
Very few are truely versed in DBMS (Relational or otherwise). Also, if
you have a system which produces comfortable results on 5 out of 6
issues, it is difficult to agree to switch the whole system. And
rightly so. The missing functionality may not be critical, the fear of
losing the first five, etc. are all valid considerations.
As I said, my take on this issu is that I would like to try and prototype
it into a database. a SQL based one. I am NOT saying it will be better,
nor faster, as I sinmply do not know yet. I like the RDBMS option as it
potentially has many runtime advantages. RDBMS tend to pay back on LARGE
databases of complex nature. This is NOT true, as poor implementation can
screw up beyond comprehension.
>> Oracle based is good. Now, plase tell us how to run Oracle on FreeBSD,
>> legally, and with source available.
>
> You can't (yet). But should I get the chance to implement something
> Oracle based at work, I should be able to at least apply that learning
> to reimplementing it in Postgres.
Almost True. But, maybe I get the time and do it in Postgres. I think I
know how to do it in Oracle already. Then you can learn from my experience
:-)
...
> My initial thoughts on this (and I have done *very* little reading on the
> subject at the moment) is to use the database only for the threading
> information. Store all the message information somewhere else, with an
> efficient way to
This is not necessarily true.
..
I quite disagree with the design as you outlined it. It would have been OK
for DBM or some such. I'll get back to you with my humble opinion, once I
complete it.
> [1] I don't like implementing 'quick solutions' any more than the rest of
> you, but I was outvoted on this one.
You were not outvoted, as there was no vote.
----------
Sincerely Yours,
Simon Shapiro
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-database" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980331083941.shimon>