31–40 of 62 posts
Why refer to the database that didn't fit this use case as "the particular NoSQL database that we selected", while specifically mentioning the one that DID fit by name? I know Postgres is great, no convincing necessary :)
Earlier quoted context omitted.
This is only if you ignore why people moved to NoSQL in the first place. PgSQL is great for a lot of things, but I would argue that if you're using it you're betting on your overall product/service having some other killer advantage than data processing. The competent wing of the NoSQL crowd are using it in strange ways that enable new classes of product and service that cannot be achieved with PgSQL.
Can you give examples? I assume you're talking about hadoop-related tech, but you left it vague.
My broader point is that if your project fits into pgSQL then you need another unique selling point and the data functions are just an implementation detail of some other aspect of your offering, whereas for many of the people not using that kind of thing their analytics and data systems are their selling point. (That's a backhanded compliment to pgSQL, in that it's easy enough to get right on small systems that any competent developer should be able to manage it, thus reducing the market value though). There is, of course, the blurred line of crazy MySQL deployments, many of which are barely relational.
The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages. The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tabl…
Safari, Chrome and Opera implement WebSQL using the public domain SQLite library. This means WebSQL is available on almost all smartphones/tablets and on the majority of PCs.
Btw. Mozilla implemented their "NoSQL" IndexedDB on top of SQLite in the first place. Various features like bookmarks are also stored in a SQLite database. As well as in FirefoxOS.
The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages. The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tabl…
Earlier quoted context omitted.
I really don't understand this argument. They were able to throw up IndexedDB support from scratch in a jiffy, but because something that actually works on nearly all platforms (including mobile!) happens to be Chrome's (??) that is a reason to hold back? Sqlite has been around for almost 15 years now. It's time to adopt it as a standard. Even if they're not satisfied with it, they can easily put a 'draft' stamp on i…
> They were able to throw up IndexedDB support in a jiffy, but because something that actually works on nearly all platforms (including mobile!) happens to be Chrome's (??) that is a reason to hold back? No, because the proposed spec did not actually specify the behavior in a way that was independently implementatble . The spec did not specify the supported query language, either by simple reference to a specific ver…
Istill haven't seen any argument on why it isn't possible to freeze it at some point and agree on the fact that that's already an interoperable standard that works in the field right now.
This is IMO still an the result of a NoSQL biased group of people that decided to go another way for the sake of being cool. SQLite is specced and tested inside out and back and forth (LITERALLY!) You can write a spec on that better than you can write a spec on how IE 6 behaves.
I cannot criticize him for leaving Couch|Mongo if their data is rich in relations, but I would like to read his thoughts on graph databases for instance.
Maybe their data is too large for Neo4J, but for querying n:m relationships, this model can offer advantages.
The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages. The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tabl…
> The NoSQL data model - please read as document oriented > is fundamentally flawed because it forces you into > denormalization... Can you provide an example? How does it "force" this?
Start anywhere, for example, pick your users and create a document for each. Now you take the orders of each user and also put them into the document belonging to the respective user. Fine, that works. Now we come to the products they ordered, and now we have a problem. Unless no product has ever been ordered by two different users we have to duplicate product information and put it into several different documents. And there is the same problem within documents if the user repeatedly ordered the same product.
All interesting problem domains just don't fit the idea of piece of JSON without references, internally or externally. There is of course support for reference in document oriented databases, but then lets just call your documents rows in a table and your references foreign keys and we are almost back at the relational model besides that documents still have a richer model, a bit like a NF² relational model or database with deep support for XML or JSON columns.
Earlier quoted context omitted.
One thing that is not easy to do with a relational model, is offline synchronization for high-availability on mobile devices. The document model was built for this, I find it hilarious that so few of the NoSQL databases are taking advantage of the latent capability. Try out Couchbase Mobile http://mobile.couchbase.com and compare it to best of breed relational sync.
It is not hard at all. people just hadn't built as much of the tools for it. Which also confuses me because we now have package managers that run on package managers. My own little WebSQL Object/Relation mapping library uses promises to get away from callback hell, and it's a pure joy to work with. It handles creating tables and inserting fixtures before the first connect promise is returned, so that you don't have t…
Sadly one cannot use it everywhere as WebSQL is not implemented in Firefox nor IE :(
The good thing is WebSQL works also great on mobile devices.
The NoSQL data model - please read as document oriented - is fundamentally flawed because it forces you into denormalization without good reasons like performance optimization but with all the disadvantages. The only good reason not to use a relational database is that they suck at modeling complex entities and their relationships. Shattering nice entities into small relations to get them normalized, adding join tabl…
> The NoSQL data model - please read as document oriented These few words are pointing to a fundamental problem I'm already getting annoyed about, as little as I know about "NoSQL" databases so far: The term NoSQL-database is flawed, just as Fowler says in his introduction talk. Theres's document-oriented databases, and array-ish data storages (column family-oriented), there's graph based databases - and they have ve…
[1] Actually I said that in my first comment, but the wording is just bad and probably way to sensationalistic. What I really wanted to say is that it is a really bad fit for modeling you usual business with user, orders, products and the like.
Earlier quoted context omitted.
> They were able to throw up IndexedDB support in a jiffy, but because something that actually works on nearly all platforms (including mobile!) happens to be Chrome's (??) that is a reason to hold back? No, because the proposed spec did not actually specify the behavior in a way that was independently implementatble . The spec did not specify the supported query language, either by simple reference to a specific ver…
> It was, therefore, not possible even in principle to have mutually-compatible, independent implementations (and all of the existing implementations just did "link to some version of SQlite and do whatever it does".) SQLite library is in public domain, has more lines of code test cases than lines of code C library code and its SQL API is stable. Plus the SQL language is well documented: https://www.sqlite.org/lang.h…
The fact that SQLite is available is entirely irrelevant to any of this. The W3C can't just say "do it like SQLite does it" - that's not a standard. The WebSQL spec that exists says:
> User agents must implement the SQL dialect supported by Sqlite 3.6.19.
Unless someone actually sits down and goes through the standardisation process to define WebSQL properly, this is not the way to go, or the next thing will be "implement this tag like Firefox does".