Hacker News new | ask | show | jobs
by raverbashing 4572 days ago
Condescending much?

Yes, migration happen at read time (translating on the fly may be a possibility without rewriting old documents as well)

Of course doing this is easier than adding manually columns every time you need to change something. PGSQL fans love to say how this works wonderfully in theory but in practice it's not as pretty as it looks like.

"SELECT date, carrier, zone, COUNT(id), SUM(price) FROM shipments GROUP BY date, carrier, zone;"

Nice try, but no.

This select doesn't even match your proposed CREATE TABLE above. It's at least missing a JOIN.

And the 236 lines of JS, well, there's a lot of specifying fields, (22 of them), so, if you do that on SQL you'll end up with lots of lines as well or at least an ugly to read line.

"I don't get it. How is mongodb even remotely the right tool for this job?"

Of course, it's hard to find someone who uses MongoDB respecting its limitations and using it appropriately, most MongoDB hating posts are similar to "I'm trying to attach a trailer to my motorbike and it doesn't work, I also tried taking it onto a lake and it broke, this sucks"
1 comments
yummyfajitas 4572 days ago
Go read his code. He's specifying a bunch of fields like this:

    'zone_2': 0,
    'zone_3': 0,
    ...
My SQL query already handles that simply by making `zone` one of the columns. Seems I missed the `shipment_type`:

    SELECT date, carrier, zone, shipment_type, COUNT(id), SUM(price)
           FROM shipments GROUP BY date, carrier, zone, shipment_type;
That replaces another 7 of his lines (`next_day_air: 0, ...`). It's also future proof - if a new shipment type or zone is added, the bog standard SQL code still works.

Those fields would need to be on the create table. The simplified create table I wrote was simply to illustrate the fact that SQL also handles the issue of "We rarely used most of these entities without the other". Or maybe you would join against them, in which case my 3 line solution becomes 4-5 lines.

It's not for nothing that people like to build SQL on top of Hadoop (see Hive, Impala). SQL queries are nearly always a lot simpler than comparable MapReduce code. (I find these efforts misguided, but separate issue.)

link