31–40 of 224 posts
Earlier quoted context omitted.
Mongo's debut was well timed to ride the JSON crazewave.
Sorry for my ignorance, but what JSON craze?
Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…
CREATE TABLE documents (name text, tags text[]);
INSERT INTO documents VALUES ('Doc1', '{tag1, tag2}');
INSERT INTO documents VALUES ('Doc2', '{tag2, tag3}');
INSERT INTO documents VALUES ('Doc3', '{tag2, tag3, tag4}');
SELECT * FROM documents WHERE tags @> '{tag1}';
name | tags
------+-------------
Doc1 | {tag1,tag2}
SELECT * FROM documents WHERE tags @> '{tag2}';
name | tags
------+-------------
Doc1 | {tag1,tag2}
Doc2 | {tag2,tag3}
Doc3 | {tag2,tag3,tag4}
SELECT * FROM documents WHERE tags @> '{tag2, tag3}';
name | tags
------+------------------
Doc2 | {tag2,tag3}
Doc3 | {tag2,tag3,tag4}
Earlier quoted context omitted.
Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.
> Why not just use a SQL db that handles json and stick everything in a couple columns? Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.
I actually think NoSQL might be better for MVP and prototyping. Why? Because they can handle churn more quickly, and you don't have to worry about scale. Once the data layer starts to resonate around a solution ... then pick the right horse for it.
Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.
MongoDB was great to me for prototyping, either manually or with tools like Meteor.
I actually think NoSQL might be better for MVP and prototyping. Why? Because they can handle churn more quickly, and you don't have to worry about scale. Once the data layer starts to resonate around a solution ... then pick the right horse for it.
Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.
I can't just make calls from Html + JS to Postgres.
But I can with MongoDB
Earlier quoted context omitted.
Mongo's debut was well timed to ride the JSON crazewave.
Sorry for my ignorance, but what JSON craze?
The only "advantage" to JSON is that it maps directly to the object trees most developers use in their scripted programs (which is misguided IMHO).
Earlier quoted context omitted.
Sorry for my ignorance, but what JSON craze?
As a serialization format, JSON is horrible. Way too loose regarding formatting and way too much noise. All that is typically needed is a standard text format for relational data. I.e. a fixed CSV. The only "advantage" to JSON is that it maps directly to the object trees most developers use in their scripted programs (which is misguided IMHO).
The problem was that the "velocity" blocking requirements could be completely arbitrary, and could be anything a merchant required as long as they used any of the data that was available from the transaction/previous transactions - block a transaction if it's more than 500 GBP and we've had 3 other transactions greater than 500 GBP in the same country in the previous 10 minutes.
This essentially meant we would either have to do dev work whenever a merchant had a new "velocity" rule, write our own complex framework to handle the addition of arbitrary rules, or just stuff the data into a schemaless NoSQL store and then leverage the power of the engine's query syntax as part of the merchant's configuration.
We went for the schemaless NoSQL solution and we used mongodb v1.6 - around 2010 IIRC, before it reached peak hype, before it "fixed" a lot of the out of the box defaults, before it got a lot of hate. It worked perfectly and ran from the time we deployed it until i left the company a few years later. Maybe I left a mass of technical debt, but the solution ended up being so simple and so little code I doubt it.
The other nice thing was that the velocity system was not essential - if the time to do a velocity check took more than 0.05s we would ignore it. If the backend wasn't responding we ignored it. If the write to the storage failed it didn't matter. We didn't need to keep more than a couple of hours worth of data. If we lost all of that data it didn't matter.
I don't know if I'd take the same approach now, nine years later, but at the time the use of mongodb worked perfectly. It was only a couple of weeks work, and solved the problem elegantly. So in response to the original question: yes, but as usual RTFM and make sure the pros and the cons fit your use cases.