tag:blogger.com,1999:blog-1044905565558039254.post3366298133961467008..comments2023-04-26T05:39:11.329-07:00Comments on Software Simplexity: Picking a NoSQL DatabasePeter Krienshttp://www.blogger.com/profile/11373850803487010328noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1044905565558039254.post-28629020934680765152012-04-29T23:52:19.322-07:002012-04-29T23:52:19.322-07:00@John: I do recognize the issues you raise but in ...@John: I do recognize the issues you raise but in a way they are similar to SQL or any database. The choice when something is a document (table) and when it is embedded (column) is the same as the old contained problem. Design, is, and will always remain, hard because it is so hard to predict what will grow and what will remain simple.<br /><br />I hope by using the Data (entity) classes I at least have a good anchor point to document the schema. Though I understand the model driven approach and always try to write table driven software EMF has always been a too big step for me. But who knows, this project might teach me.<br /><br />Interestingly, the query string in the find() method is the good old OSGi LDAP filter, this was trivially easy to convert to monogodb's query language. Since the Store class knows the Java type of the Data class I can adjust the query string type accordingly and check for existing fields.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-1044905565558039254.post-33851401329004972822012-04-27T13:03:22.161-07:002012-04-27T13:03:22.161-07:00Hello Peter,
I think MongoDB is a great solution,...Hello Peter,<br /><br />I think MongoDB is a great solution, but there are significant object to store mapping issues that surface at deployment time when optimizing large object graphs for insert and query (index) performance. <br /><br />Designing how big objects are stored in either deep documents or to normalize them across collections is the challenge. Since Mongo has no join concept, objects that are normalized across mongo collection boundaries, must be recombined using metadata references to child or parent references in other collections and it must be done with multiple distinct queries. <br /><br />Some of the problems are solved when a model driven approach (EMF) is used on top of MongoDB. <br /><br />See the MongoEMF project<br />https://github.com/BryanHunt/mongo-emf/wiki<br /><br />There is an initial simple query language and a new query project being considered as well:<br />https://github.com/tigergui1990/MongoEMF-query-engine/wiki/XText-based-query-engine-for-MongoEMF-project-proposal<br /><br />I am in the process of working up an ODA driver so one can use Eclipse BIRT with Mongo EMF.<br /><br />The week link I have encountered is with the MongoEMF query languages. While these prove to be a better solution than the Java drivers especially since they can be encoded as url queries, they still are object/model unaware, which leaves the business reports designer somewhat blind when they drill into the object graphs at report design time. <br /><br />Current plan is to supplement the MongoEMF query language with a model aware OCL interpreter to aid the report designer when drilling into objects.<br /><br />Perhaps your query language may solve these problems? <br /><br />Look forward to see what you come up with.<br /><br />JohnJohn Conlonhttps://www.blogger.com/profile/15580106055551732559noreply@blogger.comtag:blogger.com,1999:blog-1044905565558039254.post-56617117041723685922012-04-27T10:03:58.223-07:002012-04-27T10:03:58.223-07:00This comment has been removed by the author.Pelagichttps://www.blogger.com/profile/00120244880357584783noreply@blogger.com