RE: SV: [PHP] Booking by Date/Time in mySQL

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:jsnell@networkninja.com] Sent: Wednesday, March 21, 2001 10:54 PM To: Thomas Edison Jr. Cc: php-general@lists.php.net 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...