VietMX Staff asked 3 years ago
Problem
What’s easier, what’s harder, what can’t be done at all?
I’m answering this with MongoDB in the back of my mind, but I would presume most would be true for other DBs also.
Harder:
- Consistency is not handled by the database but must be dealt with in the application. Less guarantees means easier migration, fail-over and better scalability at the cost of a more complicated application. An application has to deal with conflicts and inconsistencies.
- Links which cross documents (or key/value) have to be dealt with on application level also.
- SQL type of databases have IDEs which are much more mature. You get a lot of support libraries (although the layering of those libraries make things much more complex than needed for SQL).
- Keep related data together in the same document could be tricky, since there is nothing corresponding to a join.
- Map/reduce as a means of querying a database is unfamiliar, and requires a lot more thinking than writing SQL.
Easier:
- Faster if you know your data access patterns (views or specific queries).
- Migration / Fail-over is easier for the database since no promises are made to you as an application programmer. Although you get eventual consistency.
- One key / value is much easier to understand than one row from a table. All the (tree) relations are already in, and complete objects can be recognized.
- No designing DB tables
- No ODBC/JDBC intermediate layer, all queries and transactions over http
- Simple DB-to-object mapping from JSON, which is almost trivial compared to the same in SQL
