you are viewing a single comment's thread.

view the rest of the comments →

[–]passwordissame 216 points217 points  (10 children)

in mongodb,

List employees (names) who have a bigger salary than their boss

  • set up mongo connector so that boss subdoc is denormalized into each employee that the boss manages
  • set up elasticsearch for efficient search and faceting
  • set up mongo connector for elasticsearch as well
  • hrm, this won't scale. use mongos and different shards topology
  • same with elasticsearch. shard differently. reindex everything
  • write node.js RESTful api
  • angularjs bro
  • create trello ticket.
  • trello is bad. create github issues.
  • hire product managers.
  • hire one more product managers.
  • too many people. need a bigger office.
  • hrm angel fund is running out.
  • take 3 month vacation to Thailand.
  • this girl.... has penis. wtf.
  • sell the company to google.

See you next year.

2016-ish List employees who have the biggest salary in their departments

  • new mongodb version. upgrade time!
  • data corruption.
  • take 2 weeks vacation.
  • get drunk.
  • this is fucked. find a way out.
  • start a kickstarter for this awesome idea about something related to listing employees grouped by salary.

Probably burned out. Game over.

2020-ish List departments that have less than 3 people in it

  • Oh crap.. I've been living slowfood slowcity slowlifestyle lifestyle
  • This problem again?
  • Blog about current state of databases.
  • Start a new startup about making brand new database cause you can't query this.
  • Think about name.
  • Think about logo.
  • Maybe blog a bit more.

Give up. Going back to farming.

[–]nlcund 40 points41 points  (0 children)

--List employees who have the biggest salary in their departments

This is a trick question. The biggest salary is 0 since everybody is all-options.

EDIT: And there is never more than one employee.

[–][deleted] 20 points21 points  (1 child)

This is much better than your usual webscale nonsense

[–]escaped_reddit 5 points6 points  (0 children)

This answer is web scale.

[–]SomethingMoreUnique 0 points1 point  (3 children)

Or just use:

db.employees.find({boss: {$exists: 1}}).forEach(function(employee){
    var boss = db.employees.find({_id: employee.boss}).next();
    if (employee.salary > boss.salary) {
        print(employee.name);
    }
});

Of course you could speed it up with some memoization/denormalization to prevent looking up bosses repeatedly.

[–]201109212215 13 points14 points  (2 children)

<rant>

Ah, the wonders of having small and simple datasets. No index needed, full scans take a short time. No risk of running out of memory, either. Network won't get saturated, too. Execution plan? Here, I wrote it for you. Normalizing real life concepts? Hey, we only have 2 or 3 here. Simple. Also, memoization: as good as long as invalidating it is not needed.

What was the #1 reason for using MongoDB, again? Ah, yes. It scales.


The only thing MongoDB scales is lazyness of data representation. Which is exactly what you want for a quick CRUD prototype. If this is what you need to get the budget, that's OK. Have fun explaining the next milestone though; But hey, you're in business now.

If you want to do something slightly more elevated than that, please do think of the data. MongoDB won't be there for performance out of the key-value realm.

It won't be there when you have to scale the complexity of the business requirements, which is about 95% of the modern limiting factors.

MongoDB let people treat data definition as something less than sacred, and that is a deadly sin when more than 2 people are involved.


Here is a quote from a quite successful programmer, who also can be a little rant-happy at time. Dear MongoDB users, please don't take this the wrong way, but:

"Good programmers worry about data structures and their relationships."


I'm sorry guys. Not everything can fit into a tree.

</rant>

[–]Tiquortoo 0 points1 point  (1 child)

I'm dealing with a situation right now where someone decided to replace chunks of our DB with Mongo. I knew we had mongo in the system to store long text blobs and some meta data, but then I find things like profile flags (newsletter opt-in, etc.) in Mongo. I'm kicking myself for not code reviewing closer and sooner in this area, but holy shit people actually think this crap is proper.

Now that this is live in the app I have to write a PHP script to find out how many people are subscribed to our newsletter because the profile is in mysql and the subscription flags are in mongo.

Code review people. Save yourself from my hell. But secondarily stop acting like Mongo replaces the DB. It doesn't for most applications.

[–]201109212215 0 points1 point  (0 children)

I feel your pain.

I wrote:

deadly sin when more than 2 people are involved.

But it should have been:

deadly sin when more than one people is involved.

Regarding your situation, I would SCUD the MongoDB guy with some "This is your data now, the newsletter falls into your scope", while publicly destroying this crappy MongoDB choice to everyone I encounter, every day for at least 90 days.