Earlier quoted context omitted.
what does PFYs stand for?
Pimply-Faced Youth :)
The PFYs need to read some BOFH. :)
Think before you Mongo
51–60 of 101 posts
Re: Think before you Mongo
#52I 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…
I would say the latter and the former are inexorably intertwined; i.e. Mongo causes problems for companies because it does things you would not expect a database to do, like your example of phantom indexes...and pretty much all bets being off when you try to leverage sharding... the one thing it was supposed to be able to do to scale...
Re: Think before you Mongo
#53Earlier 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…
[deleted]
Re: Think before you Mongo
#54Earlier 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…
I think NoSQL is mainly driven by the fact that Mongo became the defacto standard in Node-land (eg, MEAN).
Re: Think before you Mongo
#55Think before you Nodejs.
Think before you anything.
Re: Think before you Mongo
#56like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…
Amen, brother!!!
Re: Think before you Mongo
#57Earlier quoted context omitted.
Not nodejs, but I am in the process of tracking down and event loop loop (e.g. emit( event_id ) somewhere in the path of an event lisener of that name). I assume this can happen within node too. The stack trace is amazing to see.
What tool are you using that allows you to see the stack trace on async events? That seems like a good debugger.
The code is based on boost asio, so the io_service is on the same thread as your code if you only start 1. Then after that I am in gdb/ldb. Asio's io_service handles the async calls portion and dispatches to my callback. From there on it is no longer necessarily async. The fun is that I have a higher level event handler sitting above this to register/unregister listeners, like one would in node. If one of those listeners happens to emit a message to what is is also listening for, boom.
long store short, it's not the async code per say, but after that.
Re: Think before you Mongo
#58Earlier quoted context omitted.
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.
you ignored the silver bullet criticism i don't think so, i simply refuse to have my arguments framed that way since i'm very well aware of the shortcomings present in what has so far passed for a "RDBMS". i consider velocitypsycho's argument ("Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet.") a non-sequitur: the former is a proper superset of the latter, that sent…
It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".
Re: Think before you Mongo
#59Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.
Any particular reason you want it at the db layer? Wouldn't having it at the query builder/orm layer suffice?
Re: Think before you Mongo
#60> Building an MVP on a super-tight schedule (early-stage apps, school projects, hackathons, etc.) This sounds like Proof of Concept, not Minimal Viable Product.
Still almost always better off on SQL (Lite or Postgres).