151–160 of 298 posts
Earlier quoted context omitted.
Tell that to AWS. They've banned relational databases for specific workloads because Dynamo (nosql) provides more consistent performance, and is easier to operate. Tons of conflation of Mongo's problems with those of nosql in this thread.
It couldn't possibly because they're trying to push use of their own technology to force dogfooding.
Earlier quoted context omitted.
Do you think all of the companies that chose Cassandra and Dynamo were wrong to do so? There's no use case for NoSQL? There were no lessons learned, value adds from NoSQL? How do you explain the 'NewSQL' approach, which seems to be so clearly borne of what we've learned from NoSQL? It should be obvious that NoSQL has value, regardless of the issues with one of the earlier NoSQL DBs.
I don't see a value other than fashion driven development, specially when comparing the bare bones browser GUI for Dynamo with something like SQL Server Management Studio or that whole story with primary and secondary indexes, with prices being set by index usage.
There is certainly merit beyond fashion to the dynamo architecture, and there are workloads where (for example) HBase is simply the correct type of tool despite the lack of polish of its management interface
Earlier quoted context omitted.
In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.
> In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. You'll have to provide some proof for that assertion, especially given that there are numerous examples of apps doing exactly that. For example, Firefox stores bookmarks and history in an SQLite database.
Sqlite is only really viable if you don't have an undefined amount of nodes pushing commits into the DB
That's a challenge desktop applications don't have
Earlier quoted context omitted.
It couldn't possibly because they're trying to push use of their own technology to force dogfooding.
That might make sense if they didn't also offer a plethora of their own built-in-house as well has managed oss relational DBS.
Earlier quoted context omitted.
> In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. You'll have to provide some proof for that assertion, especially given that there are numerous examples of apps doing exactly that. For example, Firefox stores bookmarks and history in an SQLite database.
I'm pretty sure he's taking about web application... Sqlite is only really viable if you don't have an undefined amount of nodes pushing commits into the DB That's a challenge desktop applications don't have
From https://www.sqlite.org/whentouse.html:
"The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."
{ "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } }
How do I store it? To me, NoSQL seemed like the choice in the past.
This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as it is much simpler.
How do experienced Node devs solve this issue? Is it simply relational all the way? Is it Postgress's JSON field..?
A silly, genuine question: when I'm writing a NodeJS app, and I need to store a JSON in a DB that looks like this: { "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } } How do I store it? To me, NoSQL seemed like the choice in the past. This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as i…
https://blog.codeship.com/unleash-the-power-of-storing-json-...
A silly, genuine question: when I'm writing a NodeJS app, and I need to store a JSON in a DB that looks like this: { "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } } How do I store it? To me, NoSQL seemed like the choice in the past. This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as i…
postgres has a jsonb datatype that works pretty much like mongodb. https://blog.codeship.com/unleash-the-power-of-storing-json-...
Earlier quoted context omitted.
Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…
For most languages and frameworks, using Postgres as opposed to sqlite is barely a higher cost if you’ve got the ops skills. I’ve yet to see an app that straddled this local/web-scale line where SQLite was a better choice or Postgres wasn’t the obvious choice. There isn’t some massive cost to using Postgres instead, is there some desktop divide I’m missing here?