Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NoSQL No More

technosophos.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: NoSQL No More

#51

Post by mamcx »

jchrisa wrote: post #22
danbruc wrote: post #6

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…

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.

I have think about use it, but still it fail if the data is relational. I have a invoice app, and none of the NOSQL I have evaluated guarantee the order of the updates or have atomic updates (need both). Is not fun if a invoice update partially or the related tables get out of sync.

In the other hand, I'm stuck in how sync with a relational model :(

So, it sync well and broke my relations and transactions or it sync hard but keep my data correct.

Re: NoSQL No More

#52

Post by jeffdavis »

vertex-four wrote: post #40
frik wrote: post #28

Earlier quoted context omitted.

> 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 point is that someone has to actually sit down and define the exact feature set that a WebSQL implementation is supposed to implement, such that a development team could sit down with a copy of the standard and no other code and implement their own WebSQL implementation from scratch. 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'…

To be more specific: let's say SQLite has a bug which manifests differently on different platforms. It would be impossible to adhere to the standard.

Re: NoSQL No More

#53

Post by frik »

SchizoDuckie wrote: post #49
frik wrote: post #47

Earlier quoted context omitted.

Short: WebSQL enables more powerful web applications. It allows some online features to be used offline. It's not about SQL it's about a proper relational database with tables, indexes, ACID, etc. You may remember Google Gears ( http://en.wikipedia.org/wiki/Google_Gears ), even back in 2007 one could use the Google Mail (GMail) web interface during a flight, train ride, etc. to read mails, write mails, edit drafts, e…

I would immediately support this. This conversation needs to be started again. I'm gonna ping some people on twitter. I've just searched for a WebSQL on IndexedDB adapter yesterday and it's certainly possible, but it's a nightmare from the perspective of any sane person. This polyfill I found runs SQLite compiled with CLANG to javascript, which means running 2MB of javascript to support something that they already su…

Great. We would need a blog post that lands on the HN front page and some other HN readers that are equal minded. Or a contact to Mozilla devs.

There is also a similar one called SQL.js - SQLite compiled to JavaScript through Emscripten (probably a big library too): https://github.com/kripken/sql.js

Re: NoSQL No More

#54

Post by jeffdavis »

fidotron wrote: post #50
jeffdavis wrote: post #43

Earlier quoted context omitted.

I'm trying to follow this reasoning. I guess the idea is that if a system has a smaller market share, then it's less likely to be used by your competitors, and can therefore offer a competitive advantage. Is that right? That doesn't make sense to me because it only really applies when there is a high likelihood of competitors using one product but not the other. Although postgres is doing great, in most markets it's…

That's not quite my reasoning, so I'll try again! pgSQL does what it does easily enough that it reduces the barriers to entry to such a level for traditional RDBMS workloads (which there are plenty of) that such workloads are simply not economically worth pursuing (especially for startups) except as small components in larger systems where the value add is elsewhere. The "other" world of big data/time series/graphs/n…

Oh, so it's a barrier-to-entry argument? That makes more sense. The barrier to doing something with postgres is pretty low, so competitors can more easily copy your ideas unless there are more barriers somewhere else.

An interesting point. More broadly: if what you're working on is not hard (and awkward), then others can copy your idea easily. Technology like postgres makes a new class of problems easy, and thus you need to find new problems to solve if you want a sustainable business.

Re: NoSQL No More

#55

Post by SchizoDuckie »

jeffdavis wrote: post #52
vertex-four wrote: post #40

Earlier quoted context omitted.

The point is that someone has to actually sit down and define the exact feature set that a WebSQL implementation is supposed to implement, such that a development team could sit down with a copy of the standard and no other code and implement their own WebSQL implementation from scratch. 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'…

To be more specific: let's say SQLite has a bug which manifests differently on different platforms. It would be impossible to adhere to the standard.

May I refer once again to http://sqlite.org/testing.html and the fact that it's running in the real world on millions of devices? This is a non-argument in this discussion! What if IndexedDB has a bug which manifests differntly on differnt platforms? You would refer to the specs, which can be tested.

Re: NoSQL No More

#56

Post by platinumdragon »

I agree with the overall premise that the technology you choose needs to match your problem, however it's unfortunate that the author seemed to think that NoSQL is only about document-based databases, and didn't do any research into something like a graph database. It would have been interesting to see if that would've met his needs better than taking his ball and running home.

Re: NoSQL No More

#57

Post by jt2190 »

danbruc wrote: post #37
jt2190 wrote: post #23

Earlier quoted context omitted.

> 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?

If you want to use a purely document oriented model and not have redundancies then you have to partition your object graph into a set of documents that do not overlap and have no relationships between them. I can not think of any real example that fits this model. 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 belon…

  > Now you take the orders of each user and also put them 
  > into the document belonging to the respective user.
So the database doesn't force anything. The data modeler makes a questionable decision.

  > All interesting problem domains just don't fit the idea 
  > of piece of JSON without references, internally or 
  > externally.
These databases won't prevent data modeling using references, they just often don't provide as much support as a relational database does for doing joins or enforcing key constraints.

Re: NoSQL No More

#58

Post by danbruc »

jt2190 wrote: post #57
danbruc wrote: post #37

Earlier quoted context omitted.

If you want to use a purely document oriented model and not have redundancies then you have to partition your object graph into a set of documents that do not overlap and have no relationships between them. I can not think of any real example that fits this model. 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 belon…

> Now you take the orders of each user and also put them > into the document belonging to the respective user. So the database doesn't force anything. The data modeler makes a questionable decision. > All interesting problem domains just don't fit the idea > of piece of JSON without references, internally or > externally. These databases won't prevent data modeling using references, they just often don't provide as m…

But that's my point - either you use documents in the way they are advertised and get redundancy or you normalize into many documents with relationships between them and then your documents just degenerate into entities.

I am not saying there are no usecases where a document oriented model fits well, but I argue that it is not a good fit for modeling your average business.

Re: NoSQL No More

#59

Post by jt2190 »

danbruc wrote: post #58
jt2190 wrote: post #57

Earlier quoted context omitted.

> Now you take the orders of each user and also put them > into the document belonging to the respective user. So the database doesn't force anything. The data modeler makes a questionable decision. > All interesting problem domains just don't fit the idea > of piece of JSON without references, internally or > externally. These databases won't prevent data modeling using references, they just often don't provide as m…

But that's my point - either you use documents in the way they are advertised and get redundancy or you normalize into many documents with relationships between them and then your documents just degenerate into entities. I am not saying there are no usecases where a document oriented model fits well, but I argue that it is not a good fit for modeling your average business.

I'm guessing that "the way [documents are] advertised" refers to some of the "hello world"-style examples that are found in various blogs. I'll agree that in their enthusiasm for showing how easy it is to use put data into and retrieve data from a document store (no O/R mapping!) they assume that the reader is well-versed in data modeling. This has bitten numerous inexperienced developers. I've never seen an article recommend against data normalization though.

Re: NoSQL No More

#60

Post by mrcsparker »

vertex-four wrote: post #40
frik wrote: post #28

Earlier quoted context omitted.

> 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 point is that someone has to actually sit down and define the exact feature set that a WebSQL implementation is supposed to implement, such that a development team could sit down with a copy of the standard and no other code and implement their own WebSQL implementation from scratch. 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'…

I don't understand this argument. There is already a SQL standard. Start there.
Post reply on HN