[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: (OT) mySQL vs. Oracle
- From: Michael Jinks <michael twopoint com>
- To: redhat-list redhat com
- Subject: Re: (OT) mySQL vs. Oracle
- Date: Sun, 31 Jan 1999 19:27:49 -0600
"Chad W. Skinner" wrote:
>
> Since I work for a school district I am concerned about having the district
> fork over the 8,000- 10,000 in TAX dollars to get oracle when in my
> understanding it would be overkill.
This doesn't come real close to answering your question either, but if
mySQL does turn out to be insufficient that doesn't have to mean Oracle,
or even Informix for that matter. PostgreSQL is a full-featured
database back end that should do just fine for a database like yours,
and it doesn't cost a dime. I've only played with it (haven't had to
take it into production for anything yet) but I like it a lot.
I don't know what was meant by "making the client work harder." As far
as I know, a web-ified database shouldn't put much strain on the client
at all; the client forms its query, spits it to the database, and waits
for a reply. Seems to me that's the whole point behind SQL in the first
place. If you use a complicated query formation process, then sure the
client will work harder than if you just have (say) a bunch of static
URL's. But that doesn't have any bearing on the back end you choose.
I don't know much about your situation, but if you're a Perl nut at all,
you might want to look into the Perl DBI. It's a set of tools which
allow you to write client-side apps in Perl which can access any of a
large number of database back-ends, each through its own driver. Then
you can mix and match back-ends (even Oracle has a free one for trial
purposes) while you test for things like response speed or whatnot. You
might find that Oracle doesn't offer much advantage at all over more
affordable solutions.
Cheers,
m
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]