Migod! ALUG Library's...come back to life!
OK so no-ones ripped a new one in the idea of a peer-peer ALUG Library. That's nice; I assumed we'd go that way so I've quietly been doodling around with the concepts.
Have not thought about consequences of wandering people; don't think it's too much of a problem insofar it's generic & will not go away. I'm for doing no more than normal add-person, delete/edit person etc. Um? fine person? New joiners give a sub which they get back when they go LESS losses? Could be expensive. Perhaps a borrowing cap is in order. Another table... NOPE a new attributes of the Person table; default say 4.
This might as well be a progress report on what I've done, so here goes.
Top level concepts as last reported + thoughts on this issue:
Are there any issues if item passed to wrong person. Example: Person A has WonderBook which everyone wants. Person's B,C,D etc. request it. B is at top of list.
At the next meet everyone is there except B. Oh dear a ruck forms; A & book disappear from view & when tussle clears D has made off with it. "Well, B had their chance."
Is this legal? Don't see why not; B could well miss a meet & it seems fine to me that someone else gets the book. For this to work, everyone must have been issued a key to give A. That may mean another table for the confirmation keys rather then finding a home for <the one key> in say the Transaction table.
Alternatively if it's NOT OK to passover B what then? Perhaps C only should be allowed to have the book, not D as decided in the tussle?
My instinct is that the more flexible the better; so I'd plump for "issue N confirmation keys & let people decide for themselves". There are more arguments around this area (the confirmation key is now effectively a person ID, so why keep on scrambling it?) but overall I'm happy with this. It's more secure / difficult to defraud this way.
Next up, db progress.
Postgres is wonderful, BUT as I had everything to hand to get going with MySQL so I made a start using it (also I had another project which used MySQL).
Now when I make a start I explore problem areas. This ties in with my design assumptions which are that everything's easy - except for the problems. So I want to know what are the problems & where are they? Once these are conquered I can go back to sleep (=base mode).
First up I needed a model environment, so I put together a box networked to a PC. There's the server, here's the client <this included a big diversion fighting various Linux distros; they didn't like the ancient embedded video on the server>. MySQL goes in, fight with that. Many minor mistakes; finally import a test database for the other project; but principles established. Install MyODBC onto the PC; that is a success.
Next up how to actually do it? I want a RAD or sumfin'.
Access works well via the ODBC, but that's not PC. Hm. StarOffice 5.2! It sort of works and crashes but it's just about usable; snag it it doesn't quite fit MySQL nicely.
At this point I was going to make a start putting some default forms together. OK not for the final system; they'll have to be over the web. But these are 1st shot functional screens to get things going; SO5.2 has a GUI editor all drag'n'dropish with predefined stuff (fields, buttons, pull down lists etc) & that's nice esp. when it accesses the remote test MySQL db and I see real data in the fields on my PC. At that point I went on holiday & now it's now.
Be Warned I'm not a coder (well not in the last 15 years).
Bye Bye for now!
Steve