161–170 of 188 posts
My company got hired for 2 very large MongoDB to MySQL migration projects this year alone totaling over $170k. These apps should have never been on MongoDB in the first place. Total mess that cost them lots of $$. I am okay if others continue to use MongoDB. It will keep my team gainfully employed ;)
Earlier quoted context omitted.
> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think . And for employers, because it means they can make do with programmers who don't want to think.
> Not having to think rigorously about the logical structure of your data is a huge selling point for many I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables - I have had the pleasure of designing relational schemas for cyclic graphs. Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shi…
> I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables
That contradicts my experience. The relational model isn't a panacea, but it lets me model most scenarios adequately. Whenever the relational model is deficient, what I want is more powerful schemas (sum and product tables, constraints spanning several tables, etc.), not less.
> Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shit-show.
I'm inclined to think the problem is actually at the object-oriented end of the bridge: https://news.ycombinator.com/item?id=11861520
> With NoSQL I'll just dump the new document structure and call it a day (or rather, deal with the differences in the application layer).
Correctly managing these differences without help from schema-aware tools is rather painful.
My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place. If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store. Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a…
Pretty much the classic http://www.mongodb-is-web-scale.com/?
Earlier quoted context omitted.
That is a scary thought.
Only scary if you are locked into the past and/or closed-minded. (disclaimer: I'm not a mongo fan).
Sorry, but I don't want to work in an environment where programmers don't want to think or don't have to think. That is a scary thought. Has nothing to do with being locked into the past or being closed-minded. Just the opposite actually.
Earlier quoted context omitted.
> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think . And for employers, because it means they can make do with programmers who don't want to think.
That is a scary thought.
Earlier quoted context omitted.
That is a scary thought.
It isn't that scary once you take into account the fact that our brains are just as finite as any other resource available to us. It's a virtue not to make more mental effort than what is strictly necessary to complete the task at hand.
My company got hired for 2 very large MongoDB to MySQL migration projects this year alone totaling over $170k. These apps should have never been on MongoDB in the first place. Total mess that cost them lots of $$. I am okay if others continue to use MongoDB. It will keep my team gainfully employed ;)
If you're gonna migrate to SQL, wouldn't Postgres be a better call?
Earlier quoted context omitted.
On the flip side... joins are expensive... I worked on an application, where presenting a single page, representing a single item in the application (classifieds site) required upwards of around 40 joins (iirc 36 or 46, I don't remember)... under load (including search result pages), the app was crushed by its' own weight. I think the bigger issue is that people are afraid of separating data at clear boundaries, so l…
40 joins for a classified ad?
Like I said, it was pretty crushing on the database... there were a lot of other expensive calculations that ran per request... pre-calculating, caching, and a few other things got some longevity, bit it was a tangled mess of a beast for what would have been 3-4 collections for a document database (mongodb, rethinkdb, etc).
Earlier quoted context omitted.
Only scary if you are locked into the past and/or closed-minded. (disclaimer: I'm not a mongo fan).
I was mainly referring to "And for employers, because it means they can make do with programmers who don't want to think." Sorry, but I don't want to work in an environment where programmers don't want to think or don't have to think. That is a scary thought. Has nothing to do with being locked into the past or being closed-minded. Just the opposite actually.
Earlier quoted context omitted.
> Like the author, I really cannot wrap my head around this. While I understand that duplicating documents across collections may make querying faster, what about when you want to change the document? You need to propagate the change across every duplicate of the document in every collection where it exists. This means that any "de-duplication" logic needs to happen at the application level, rather than the database…
Indices are updated synchronously on every insert, slowing your writes, for the sake of transactional guarantees that most applications aren't written to take advantage of. Queries have to be passed over the wire as strings Those are implementation details, not inherent properties of the relational model.