> > 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.