Acknowledgements

Special thanks to Bret TAYLOR for original inspiration and battle-tested case study of Friendfeed.

Alex MARTELLI for his assistance and his Cookbook for serving up delicious Python meals.

SQLite is a C library that provides a disk-based database that doesn’t require a separate server process. D. Richard HIPP deserves recognition for putting SQLite in the public domain: solving 80% of data persistance issues, using only 20% of the effort required by other SQL databases. Thus SQLite is the most widely deployed SQL database engine in the world.

The sqlite3 module was written by Gerhard HAERING and provides a SQL interface compliant with the Python DB-API 2.0 specification described by PEP 249. His effort – updating that module from version 2.3.2 in Python 2.5 to version 2.4.1 in Python 2.6 – has been crucial to y_serial. We are counting on him to resolve bug 7723 for an easy transition to Python 3.

zlib was written by Jean-loup GAILLY (compression) and Mark ADLER (decompression). Jean-loup is also the primary author/maintainer of gzip; Mark is also the author of gzip’s and UnZip’s main decompression routines and was the original author of Zip. Not surprisingly, the compression algorithm used in zlib is essentially the same as that in gzip and Zip, namely, the ‘deflate’ method that originated in PKWARE’s PKZIP 2.x.

Lastly, thanks to our host: SourceForge.net is the world’s largest provider of hosting for Open Source software development projects. SourceForge.net provides a variety of services to projects, including collaborative development tools, and applications to support discussion and support. Such services are provided to projects and their end-users free-of-charge.

See also

NoSQL-database.org where NoSQL is defined as follows:

“non-relational, distributed, open-source and horizontal scalable. The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply as: schema-free, easy replication support, simple API, eventually consistent / BASE (not ACID), and more. So the misleading term “nosql” (the community now translates it mostly with “not only sql”) should be seen as an alias to something like this definition.”

And we also like this anthropomorphic characterization from an article entitled “Stop calling me NoSQL” :

“You see unlike RDBMS [e.g. SQL databases], I don’t require that data be clearly split into tables, columns and rows. I can work with data the way it is most naturally represented: as a tree of individual data fields, lists, arrays, dictionaries, etc. Also I do not require that you always clearly define each and every possible schema element before being able to store data corresponding to the schema. I can happily accept a schema dynamically or even work without a schema. Some of my early forms were based on key value pairs stored as B-Trees (e.g. Berkeley DB). Over the years people have figured out ways to represent the data as a set of decomposed document elements, store data spread across a cluster, replicate it for better availability and fault tolerance, and even perform post storage processing tasks using map-reduce sequences. But really what separates me from my cousin and other storage systems is that I don’t make demands on the data – I take it in its naturally found form and then store it, replicate it, slice it, dice it and glean information out of it. And therein lies my true identity – I will work with data the way the data is best represented with all its arbitrary inconsistencies and inabilities to always clearly specify a constraining schema.” -Dhananjay Nene