>
> Another thing that differentiates you from other small libraries
> attempting this sort of thing is your contacting of this list. Most of
> the readers here are used to big-data problems, where they're trying
> to make sense of the storage, maintenance, and display of millions of
> records, so it's a bit of work to scale the mind down to a situation
> such as yours.


True, my issues are completely different from those usually tackled here.
 But, still, some folks here may potentially be interested in the
capabilities this circulation system offers.  Also, y'all know what problems
can arise when thousands upon thousands of records accumulate, and I have no
idea what may go awry with this as it handles unexpected cases.  So, you
might have insights for me.


related to indexing records in the app:

Yes, as an intermediate between a title list and a solr catalog (VuFind,
Kochief), I could write a quick app that stores subject, author and pub date
from the MARC records and then do search with icontains queries.  That would
be then next biggish step.

@Dave.

Django is not a CMS, but a package of python libraries one would use to
write a CMS.  The poor use of the database would be my own fault, because I
write the queries (or python code which is compiled into SQL).  For
instance, every blog with a headline that contains (case sensitive)
 "Lennon" is executed with
Blog.objects.filter(entry__headline__contains='Lennon')

read more here if you like:
http://docs.djangoproject.com/en/dev/topics/db/queries/

Also, any host will support php, but only *most* of them support django at
the level of the cheapest possible plan.  At the second cheapest level,
pretty much any established host supports django.

University of Texas is switching to django for all of their internal DB
stuff like accounting and payroll for reasons that are obvious to anyone who
has used django.