On Mon, 2002-03-25 at 13:59, Carel Fellinger wrote:
> The nice thing of PostgresSQL is that you have a powerfull query
> language, so you don't have to program each and every usage. But..
>
> ...the disadvantage is that you have to use that query language. You
> see, those dicts are to be used in a natural language translation
> system, so *fast* access is essential in that particular usage, and
> that access is rather simplistic, just retrieve the entry on a single
> key, so there the power (and overhead) of SQL queries is not needed.
>
> So the big question is:
>
> Does anyone know whether it's possible to bypass the SQL layer in
> PostgresSQL?
No, it isn't possible.
> I've read that mySQL is based on Berkely db, so there it should be
> possible, but people seem to like Postgres better, and I certainly
> want to make it a bit more future proof this time around (the program
> has been ported with the usual problems al least 3 times before:).
mysql may be a good choice, depending on what you want to do. For
simple lookups, without much updating, it may well be faster. mysql's
weakness appears to be in running multiple updating users, in the lack
of SQL features such as subselects, lower data security (because
transactions are optional extras) and poor conformance with SQL
standards
But if you are ever going to need a real multi-user database, you might
as well go for PostgreSQL now. To speed things up, you could do
query-caching inside your application, though a simple indexed lookup is
pretty fast anyway.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
"Why are you downcast, O my soul? Why so disturbed
within me? Put your hope in God, for I will yet praise
Him, my Saviour and my God." Psalm 42:11
Attachment:
signature.asc
Description: This is a digitally signed message part