Agility, or productivity, is rarely addressed in books about new technologies, so it is refreshing to see a whole chapter devoted to this topic. As the chapter points out, it is difficult to control all the variables when comparing two technologies or approaches. Experience with older approaches increases productivity, but excitement over the next new thing can do so as well.
This chapter leaves me both intrigued and skeptical. I agree that object-relational mapping is a kludge, with tools like Hibernate doing their best to hide the fundamental impedance mismatch between in-memory objects and their persisted state in relational databases.
For simple forms that map to simple objects that map to simple backing stores, the document store story in this chapter is compelling. However, for more complex applications, where multiple objects reference each other, it seems to me that the document store approach will have to deal with the same mess as the object-relational mapping approach. When object A references object B, the reference must be transformed in order to persist it. One-many and many-many relationships need support. Transactions (allowing for commit and rollback), tracking dirty state in caching, faulting in persistent state on demand, maintaining referential integrity, supporting cascading deletion, etc. can bring significant complexity to any persistence mechanism. Can document stores and XML really support these more complex demands, and do so with greater agility than object-relational mapping? I don't know, and I would like to learn more, but silver bullets in our business are rare.
This chapter leaves me both intrigued and skeptical. I agree that object-relational mapping is a kludge, with tools like Hibernate doing their best to hide the fundamental impedance mismatch between in-memory objects and their persisted state in relational databases.
For simple forms that map to simple objects that map to simple backing stores, the document store story in this chapter is compelling. However, for more complex applications, where multiple objects reference each other, it seems to me that the document store approach will have to deal with the same mess as the object-relational mapping approach. When object A references object B, the reference must be transformed in order to persist it. One-many and many-many relationships need support. Transactions (allowing for commit and rollback), tracking dirty state in caching, faulting in persistent state on demand, maintaining referential integrity, supporting cascading deletion, etc. can bring significant complexity to any persistence mechanism. Can document stores and XML really support these more complex demands, and do so with greater agility than object-relational mapping? I don't know, and I would like to learn more, but silver bullets in our business are rare.