<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 5:20 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">The NoSQl industry is extremely successful, used everywhere, and  considered by many the child prodigee of the database industry.<div><br></div></div></blockquote><div><br></div><div>I could have sworn it is the unacknowledged hip but bastard grandchild of the network and hierarchical databases of the 60's and 70's.... so correct me where I am wrong in what follows.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>They are proud of themselves because they satisfy user needs, aka:  they store data:</div><div><div>(a) which is not in 1st normal form (aka nested, pre-aggregated)</div><div>(b) without schema</div><div><br></div><div>…to the practical  benefit of:</div><div>(a) the application getting the data out of the database exactly as the application needs it, and not </div><div>altered through a normalization phase.</div></div></div></blockquote><div><br></div><div>Which can give you blazing fast  performance IFF. But to take an example from my movie project. We have stored movie reviews by critic. You pull up a page for the critic and get all the movie reviews he has ever written. Then the client suddenly turns around (as mine did) and says I want to pull up the movie and get all the reviews the different critics have written. That query isn't going to be fast, and if you are not working with a proper query language it might not be straightforward to write. So not only do you not get a free lunch on the performance, you mind end up with a double whammy.</div><div><br></div><div>In that sense nothing has changed  from db's of 60's and 70's .</div><div><br></div><div>Enter relational and you had (after normalisation) a database design that was neutral to the queries that were to be run as there was no nesting. In addition you got a proper relational query language and  something very important - query optimisation (in theory at least) for free. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>(b) the lack of fixed schema helps with data flexibility… things change extremely quickly inside an application</div><div>those days (fields being added, deleted, changed, etc)</div><div><br></div></div></div></blockquote><div><br></div><div>How much data independence does that afford you.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div><br></div><div>So far so good, and I think until here they are all right.</div><div><br></div><div>[[ One may think that this looks a little bit like … XML, but hey, they don’t like XML. Fine.]]</div><div><br></div><div>The problems comes when they try to QUERY this data.</div><div><br></div><div><br></div><div>The NoSQL industry is re-inventing the wheel from scratch, and in a very chaotic and ad-hoc manner.</div><div><br></div><div>Just  look at the sad state of affairs in terms of  query languages and their semantics.</div><div><br></div><div><snipped/></div><div><br></div><div>==============</div><div><br></div><div>Now I can spot several mistake here:</div><div><br></div><div>1. None of those query language has a clearly designed, mathematical data model. in the absence of such a data model, that describes the input, the output</div><div>and the intermediate results of a query, how can we define a clean semantics ?</div><div><br></div><div>2. All of them have a hacky semantics — “let’s run it and we’ll se what the result is” kind of thing. The semantics in most cost corner cases — and by definition</div><div>semi-structured data is ONLY corner cases -- is not defined.</div><div><br></div><div>3. Some try to piggy back on the SQL semantics, ignoring the fact that the SQL was designed to work on relations, and JSON (or in general, nested data) </div><div>has nothing to do with relations.  SQL semantics cannot be “ported”….just because we reuse the same keywords.</div><div><br></div></div></div></blockquote><div><br></div><div>A big reason why people in Analytics who know what they are talking about are keen to use SQL is because you get query optimisation for free.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>4. None attempted to define a type system (even a basic one for atomic types like dates, and arithmetics on them..) and a schema language.</div><div><br></div><div>Now maybe it’s clear why I am so sad that the XQuery community, instead of trying to help the younger and naive NoSQL community, which still believes that</div><div>SQL is “good enough”, and using the SELECT-FROM-WHERE keywords is the magic bullet to define the semantics of any kind of query language, the XQuery community</div><div> is still looking at their own navel, and marveling, like the well known CEO: "we can handle flexible data" !!!</div><div><br></div><div>Just compare those languages I listed above with the work that has been done in the past 16 years in XQuery, and the correctness and the complexity of the result</div><div>vs, the hacky solutions above.</div><div><br></div><div>P.S. And yes, that work from XQuery was used 100% in the design of JSONiq, which was designed with the dual goal in mind:</div><div>(a) reuse 100% of the experience of design and implementation of XQuery and</div><div>(b) provide a query language that is synactically and semantically acceptable for the JSON community.</div><div><br></div></div></div></blockquote><div><br></div><div>It's called Javascript. Also known as Python.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>if we succeeded or not, that’s another story, but I am not aware of any other solution that even comes CLOSE to that goal.</div><div><br></div></div></div></blockquote><div><br></div><div>They don't share that goal. </div></div></div></div>