On Wed, Jul 04, 2001 at 09:22:37AM -0700, Paul Makepeace wrote:
> On Tue, Jul 03, 2001 at 11:57:53PM +0100, Matthew Byng-Maddick wrote:
> > Erm DB3 does transaction locks. All of the DBM routines have used locking
> > and hence concurrency has not been an issue.
>
> The issue isn't whether you have it or not but whether they render the
> thing useless when 'n' instances of a program are fighting over the
> lock.
In the case of the project I'm working on, this is never going to be a
problem. The application will use several databases and be used by, at
most, a small workgroup - say ten people. Most of those databases will
be used almost entirely for reading so have no locking issues. Those
which get lots of read-write activity will be private to the individual
user and so again there's no contention if the users are sensible.
> > This is more than can be said for MySQL with the horror that is MyISAM.
>
> I don't use MySQL :-)
Nor do I. If I have to use an RDBMS, I'll start at PostgreSQL and work up
from there.
> > > I just wouldn't bother. Go straight to the RDBMS. Bear in mind in some
> > > cases (notably Oracle, and MySQL can be made to fly too) Perl is the
> > > limiting factor, not the database. YMMV, IMO, etc
> >
> > :-) This can be the case. It depends on your disks.
>
> Not really, simply moving the stuff around in a Perl hash is slow.
Even if I use a RDBMS, my data is going to have to end up in hashes etc
so I can manipulate it. Some of them are going to be pretty complex
objects, so I have to suffer from perl being slow anyway.
--
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/
If you save all your money for three years, you'll be able to afford this
new computer. If, however, you blow all your money on poker, booze and
loose women - you'll still be able to afford it in three years.
--- anon, on Usenet
