Jon, not sure if I agree with you:
locking - almost always a bad idea, atomicity is
much faster and safer and usually indicates a better
relational design. SQL is fundamentally set oriented,
but newbies are almost always row oriented.
mySQL locks table automagically, but it doesn't do row level
locking, and transactions are only recently added.
generate ids - let the db do this with ids. Almost all
the number fountains I have seen are because of the
inability of a 3GL to recieve the generated id efficiently,
this is not a problem in mySQL. I do agree with you
though if you are refering to having a decent relational
data model
Jeffs DB Maxims:
In my db experience
OS [DOS/WIN32/Unix/Mini/Mainframe]
Type [relational/post-relational/object/network/hierarchical]
* NEVER write SQL that requires programatic locking
* minimise use of transactions [redesign! think lateral]
* use sql atomicity whenever possible
* don't be a pessimistic locker - optimism is so much more
user friendly.
* apply the twelve of codd with intelligence rather than
obsession
* all updates should be safely repeatable
* 3NF is generally cool, but 14NF is overboard.
[soapbox.off]
Kiora
-----Original Message-----
From: Jon Snell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 10:54 PM
To: Thomas Edison Jr.
Cc: [EMAIL PROTECTED]
Subject: RE: SV: [PHP] Booking by Date/Time in mySQL
Yes, I would recommend locking your tables before doing this just in case.
Another solution would be to create a unique-key based on the bed field and
date field. This way you are guaranteed never to double book, and can just
check for errors after insert rather than do an additional select statement
and worry about race conditions...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
