Okay, so figure 2.1 of the couch db book says that consistency isn’t a goal of CouchDB. So my prior post worrying about the fact that there are no foreign keys or FK constraints, etc., could result in inconsistent statement isn’t something I should worry about. Instead, I should expect that data from the database may be internally inconsistent, one record to the next, and try to minimize my reliance upon the DB to maintain consistency.
I understand that the figure probably doesn’t refer to consistency in the same way that I am, but so what? If I have data in a postgresql db, then I can make sure that the city of Orange is in Orange County which is in District 12 by using join tables. The join table data will always be consistent across db nodes, and will prevent me from making false statements about what district the city of Orange is in. At the same time, as a side effect, these foreign keys allow me to do joins in queries that let me get all of the cities in District 12. Or all of the VDS detectors inside of a city, and so on.
In CouchDB, the solution for the second problem, the query all detectors in D12, etc., is to stuff the path data you might want to search on into the document. This is bad from a design standpoint, because it forces the app to maintain the consistency of each node’s path data. Apps make mistakes. And frankly, I don’t need that sort of path searching capability. I would like to select every node in district 12, but not by city or by county or whatnot. If I really want to build the full tree, the best way is to store just the parent node, and then rebuild the tree with a series of recursive queries. The join-table side effect of consistent databases isn’t available, so I need to stop trying to use it.
