61–70 of 101 posts
Storing other people's data.
If you need to consume other services, especially if its more than one, it's hard to beat Mongo (or other NoSQL databases). You get a lot of search power (not always the easiest to tap, but you get it), and your app won't break when they change their formats. If you need a LOT of it, even better.
I would never use it as my main datastore, though. At least not for any projects I can think of offhand.
Think before you Nodejs.
Any thoughts on Amazon's DynamoDb while we all are fresh on Mongo discussion here? Thanks.
Also I know document dbs don't aggregate well, but wouldn't it be appropriate to have your app backend in NoSQL and have etl or other duplication to an rdbms or possibly cassandra?
Earlier quoted context omitted.
but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model. if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single…
Speed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.
> what purpose does precluding the latter serve?
I agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.
You have to separate between "Mongo the database" and "Mongo as it's used by companies"; the latter causes far more problems than the former. I last used MongoDB seriously in 2012-2015. We had myriad operations problems including inconsistent indexing across shards (where some shards had an index created and others didn't, it was baffling), issues with the balancer not moving chunks properly, and more. Also it's just…
+1. I agree that NoSql promotes "careless db design" to an extent.
But yes (as an example) situations do arise where you either need to alter the existing SQL table with bazillions of rows of data in it or refactor your design in an ugly-ass way by adding a 2-column table tied to the 1st table by some FK.
Earlier quoted context omitted.
I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.
NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical…
Then there's Prolog, Kanren, Mercury… which are admittedly not especially popular.
The so-called “impedance mismatch” comes mostly from people who don't understand all that SQL can do and inevitably end up replicating it in some other language.
Earlier quoted context omitted.
That'd just be Postgres. When you need an schema you use a normal table, when you need arbitrary JSON data you use a JSON schema.
I don't think so -- I'm looking for a database that will actually enforce a JSON schema for you -- I don't think Postgres has any built-in support for JSON schematization. I could always do validation before inserting data, but that opens me up to error on my side which I'd like to avoid=)
I agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.
You have to separate between "Mongo the database" and "Mongo as it's used by companies"; the latter causes far more problems than the former. I last used MongoDB seriously in 2012-2015. We had myriad operations problems including inconsistent indexing across shards (where some shards had an index created and others didn't, it was baffling), issues with the balancer not moving chunks properly, and more. Also it's just…
Earlier quoted context omitted.
I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.
NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical…
The "Object-Relational impedance mismatch" is not a result of the supposed fact that "no programming language lets you deal with relational data sanely in code", its a result of the fact that industrially popular object-oriented languages, of the time when the term was coined, did not align well with the data model supported by then-existing relational databases, and vice versa.