[REBOL] Re: Multiuser database
From: greggirwin:mindspring at: 19-Mar-2006 18:13
A> I'm making a small "Phonebook" type data base program that I want to access
A> from several computers on a local net and maybe remotely. I was originally
A> going to use a text file to store the data but I'm thinking that there is a
A> possibility that it might be accessed by two different people at the same
A> time. Without going with a MySQL database what methods can I use to insure
A> that simultaneous access will not screw up the data base file.
There is no definitive solution for this, aside from using a real
database; there are various techniques you can use though.
1) Create a "lock" file when you access the database. The first thing
you do is check for its existence, create it if not there, and
delete it when you're done. You can't access the DB unless you're
the one who created the lock file. A spin on this approach,
depending on your needs and desires, is to store actual lock data
in the file, so you can lock specific records, etc. Of course, this
can just push the same problem over to the lock file rather than
2) Use the WinAPI (or other lib access) to "lock" part or all of the
file. If you can't acquire the lock, you can't do the work.
3) Check if the DB file exists, if so, rename it (so others won't find
it). When you're done, rename it back. Doesn't work if you want to
auto-create the file of course.
4) Use the file system as your DB, storing one record per file. Works
well for small-scale apps. From there, you can build what you want
as far as extra protection, locking, versioning, etc. Bazillions of
systems use this approach these days.
None of these are perfect solutions.
A> Is this a thing for which "rebol services" would be useful?
Yes and no. If you write a DB server that serializes requests, handles
lock contention, and all the rest of the stuff a real database does,
it would be very robust. At some point, a real DB makes sense. There
are lighter-weight DBs than MySQL as well.
What is the risk, what is the worst that can happen, etc. Don't build
a solution, or a file format, that is easily corrupted; and make sure
it can be rebuilt without too much difficulty; that's the main thing
to keep in mind if you're building your own system.