Imagine this table format, and let's kind of go with the notion that these are records for actual keys:
Table: key Fields: id - Unique identifier for each key. opens - id of device the key opens. We're assuming a many-to-one relationship but that could be many to many by adding anot +her table mapping which targets share the same key. available - 0 or 1. date_created checkout_date user_id due_date
Next you would have a table, key_history:
Table: key_history id - unique history id. key_id - maps to the id of the key. action - created, checked-out, checked-in, destroyed. date_added user_id
Now whenever someone needs a key you can start a transaction, find a key that matches available=1, and opens=$target, and update that key to have the correct current user id, available=0, checkout_date = now, due_date = now + 7d. And at the same time make an entry in the history table. Use a transaction to assure that nobody else grabs the same key at the same time, and to allow for rollback if it turns out that the key has become unavailable.
Check-in should fail loudly if it tries to happen to a key id that already is checked in. Also, in this model each key has a unit of one. If you need more than one key that opens the same door, you would have multiple rows. And each user either tracks which key he has, or the application tracks it for him.
Dave
In reply to Re: Searching Database Question
by davido
in thread Searching Database Question
by htmanning
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |