That's more accurate than anything else.

I'd like to create a set of tables to describe documents, and then another set of tables to described binders, and maybe have _binders contain binders and documents. _  Since MongoDB is the hottest thing since sliced bread, the number two skill on any saleable resume, I I took the 380-odd stories (very odd stories) in my archive of stories and wrote an intake handler to create Binder objects, Document objects, and to associate the two.

I have a rather odd layout.  It's a three-tiered heirarchy of Archive, Binder, Document, and I wanted to abstract this out so that you could have many-to-many relationships among members of the heirarchy (i.e a binder will have many documents, but a document may find itself within many binders).    The current system is one-to-many: a document describes the binder it belongs to, as well as the archive to which the binder belongs.  I wrote the intake handler to "look at the archive and binder encoded in the document, and if they don't exist create them, then import the document into Mongo, then add the document to the binder record."

The race conditions in this are mind-boggling.   ObjectId encodings don't match up, so comparisons fail.  All in all, it's been a terrible couple of days trying to learn the "hot new thing."

I think I'll go back to MySQL.