Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 1999 13:46:00 -0400 (EDT)
From:      Chuck Robey <chuckr@picnic.mat.net>
To:        Dan Moschuk <dan@trinsec.com>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Database holywars?
Message-ID:  <Pine.BSF.4.10.9905201334390.69006-100000@picnic.mat.net>
In-Reply-To: <19990520130858.A94463@trinsec.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 May 1999, Dan Moschuk wrote:

> 
> | > I'd like to stay away from the commercial database suites (i.e. Oracle) for
> | > the time being, however I will eventually move to it once the database grows
> | > to over 100M records.  In the meantime however, I'm debating heavily between
> | > MySQL and Berkeley DB with a multi-threaded socket frontend.  
> | > 
> | > Suggestions and comments?
> | 
> | What's more important, flexibility to make changes, or speed?  Anything
> | that implements sql has to be far slower, but if you make many changes,
> | you're going to heavily regret choosing a set of C language functions
> | as the base of your DB.
> 
> I think a proper equilibrium between the two would be most desirable, but, if
> I had to choose one over the other it would definately be speed.  The actual
> structure of the database isn't going to change much, if at all, I would
> imagine.  Assuming it changes once a year, writing a conversion program
> to read in the old structure and write out the new one doesn't seem quite so
> horrendous.  On the other hand, its a lot more annoying than a simple 
> ALTER .. ADD statement. :-)

It's one step more complicated than that.  Moving an sql database from a
free implementation to a commercial implementation, while not perfect,
isn't all that terrible a thing to do.  Moving it from a C language
implementation to sql is going to be harsh, because it's a working
database, so you can't afford any bugs.

The DB implementation is going to be at least an order of magnitude
faster (depending on the sql database, maybe 2 orders), but if it's a
money oriented thing, do it via sql, not C.  If it's machine control
thing, often C is better.  I have a personal prejudice I'm trying hard
to mask, in favor of C language implementations, you should know that
while you read this.

Notice your client is going to matter vary much here.  As an example, if
you tell a stockbroker that you've saved him a huge amount of money at
an added .0000001% risk, that stockbroker will fire you, because they
don't care about money, they want to have it work, and they don't want
to hear about details.

Save him *time*, however, and you can count on a huge bonus!

----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@picnic.mat.net       | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770         | I run picnic (FreeBSD-current)
(301) 220-2114              | and jaunt (Solaris7).
----------------------------+-----------------------------------------------






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9905201334390.69006-100000>