NBLUG Library ?

Mark Linford public at marklinford.com
Thu Oct 24 10:57:42 PDT 2002


Augie:

I'd be happy to help out on the PHP side. As I mentioned in my
presentation (I think), I don't have a lot of experience with PEAR, but
Eric's DB abstraction points below have a lot of merit, so I'd recommend
using PEAR's DB stuff as well. Hey, it might even make a nice topic for a
future NBLUG meeting (just trying to help you out, Eric ...)

Mark



> On Wed, Oct 23, 2002 at 08:32:24PM -0700, augie wrote:
>> but mostly i was hoping to get a consensus from the nblug community
>> about whether this was something that is needed, or wanted, or if it's
>> a good idea, or bad idea. either way reply back to the list and let me
>> know what you think.
>
> I think it's a great idea.  I think it can even be done without all the
> coding you've set up for yourself, at least initially.  One pad of paper
> with a list of "patrons" (id#, name, email, any other info our librarian
> thinks we need for each person; seems like a minimum would be a
> secondary means of contact, like a phone #) and a second pad of paper
> with a list of books and the id# of who checked it out last.  (cross out
> and add a new one when it changes hands)  Or, for proper thoroughness
> and paper-based-database integrity, a 3rd sheet with PatronId, BookId,
> checkout date and checkin date.
>
> Either way, you've got my support.  I might even have a few old books in
> my personal collection that I no longer have a use for that might be
> appropriate for the library.
>
>> ps...if we do go ahead with the project we will probably need some
>> developers, so if you are looking to get your feet wet in the open
>> source software development world this may be a good opportunity. a
>> brief list of requirements, and design ideas about the project can be
>> found here:
>>
>> http://www.nblug.org/augie/nblug-lib.html
>
> Looks good so far.  Of course, I already have a list of suggestions: 1)
> if possible, make it reasonably database agnostic so that it works with
>    mysql or postgresql.  (if somebody already has one installed, they'll
> want that one)  Or, at least structure it so that anything that won't
> work with mysql is abstracted behind an interface so somebody could
> write a different module to be able to do things with mysql.  (yes,
> I'm suggesting PHP's PEAR library or Perl's DBI library, too...  none
> of this "pgsql_*" stuff.)
> 2) rename some of those fields a bit; instead of "what" use "itemId",
> for
>    instance.  More "formal" and obvious which table they refer to.
> Maybe use an id# for Patrons like you're using for Items, too.
> 3) figure out whether you like plural or singular and stick with that
> for
>    all tables; in other words, change Checkout to Checkouts and Patron
> to Patrons change Items to Item.  (I suggest the singular approach)
> 4) move the checkin date out of the Items table and over to the Checkout
>    table; then "select Items.title, Patron.name, Checkout.checkedout
> from Items, Patron, Checkout where Checkout.what = Items.id and
> Checkout.who = Patron.email and Checkout.checkedin is NULL" to find
> your currently checked out books; Then something like "select
> Items.title from Items where Items.id not in (select Items.id from
> Items, Patron, Checkout where Checkout.what = Items.id and
> Checkout.who = Patron.email and
>    Checkout.checkedin is NULL)" to find the currently available books.
> (or add two fields in Items along the lines of "Status" and
> "statusDate"; a checked in book would be status='in' -- this allows
> for the realistic possibility of a book that is supposed to be in
> (last patron checked it in) but can't be found to be checked out to
> another patron.  (For real coolness, use a trigger so that setting
> Checkout.checkedin to a non-null value sets the appropriate
> Items.status to 'out' and setting
>    Checkout.checkedout (or maybe on insert to Checkout?) sets the
>    appropriate Items.status to 'out'.
> 5) Yes, I know; in #1 I say "make it work with mysql" and then in #4 I
> say
>    "maybe you should use these SQL features that won't work in mysql".
> 6) along that status line, maybe a "hold" status in addition to "in",
> "out"
>    and "missing" for a book that somebody has requested but doesn't
> actually have yet.
> 7) CVS repository; preferably with trusted+authenticated rw access and
>    anonymous public ro access.
> 8) Get the above and some related mailing lists by setting it up as a
>    project on sf.net.  http://sf.net/projects/luglib/
>
> --
> Eric Eisenhart
> eric-dot-sig at eisenhart.com Perl, SQL, Linux and Web            ^
>       IRC: Freiheit at freenode Coder, Sysadmin and geek           /e\
>           AIM: falsch freiheit http://eric.eisenhart.com/         ---
>                    ICQ: 48217244





More information about the talk mailing list