3 ms·

MongoDB works best when it is thought of as a JSON document store. And when you do and have lots of embedded entities it becomes very fast and with its fluid s

MongoDB works best when it is thought of as a JSON document store. And when you do and have lots of embedded entities it becomes very fast and with its fluid schema a lot easier to manage and maintain. For my use case I do a single query to fetch my self contained User object which would need 30+ queries if I was using a relational database. It's an order of magnitude faster. So really NoSQL databases aren't a replacement for relational databases just another alternative.

swah 14y ago
THe only disadvantadge is that the secondary information you're storing in User - the one that would be stored in other tables - is now very hard to query. Am I right?
- taligent 14y ago
  No it is exactly the same query as if it were a separate table/collection. You can just say fetch from User.Profile instead of Profile. If you need to fetch across users then you will need an index in order to have decent performance. But the point is that in MY use case this never, ever happens so I made that tradeoff. Much faster "fetch everything about this user by id" in exchange for much slower "fetch me all profiles for all users".
  - swah 14y ago
    Yes, I was trying to understand if, for your use case, storing JSON properties for each user in a SQL text column would give the same result.
    - tomjakubowski 14y ago
      or this case could have the best of both worlds and use an HSTORE column - which can be queried by field - in PostgreSQL.
    - taligent 14y ago
      You could but then you're really trying to jam a JSON style modal into a relational database. You CAN do it. But the tools and query language will make it much harder to work with. Not to mention lack of indexes on individual fields.
      - jeffdavis 14y ago
        People avoid introducing new data stores because it adds complexity and it's harder to do queries across data sets. Jamming different data models together in one system is a very viable strategy. Postgres supports functional indexes, so indexing individual fields within a JSON document is already possible. If it's not easy now it will be easy soon. Remember XML databases? They became extremely marginalized when relational systems started adding basic support.
vph 14y ago
>For my use case I do a single query to fetch my self contained User object which would need 30+ queries if I was using a relational database. This can't possibly be right. The 30+ SQL queries would have provided additional information that your 1 NoSQL query doesn't.

swah 14y ago

THe only disadvantadge is that the secondary information you're storing in User - the one that would be stored in other tables - is now very hard to query. Am I right?

taligent 14y ago
No it is exactly the same query as if it were a separate table/collection. You can just say fetch from User.Profile instead of Profile. If you need to fetch across users then you will need an index in order to have decent performance. But the point is that in MY use case this never, ever happens so I made that tradeoff. Much faster "fetch everything about this user by id" in exchange for much slower "fetch me all profiles for all users".
- swah 14y ago
  Yes, I was trying to understand if, for your use case, storing JSON properties for each user in a SQL text column would give the same result.
  - tomjakubowski 14y ago
    or this case could have the best of both worlds and use an HSTORE column - which can be queried by field - in PostgreSQL.
  - taligent 14y ago
    You could but then you're really trying to jam a JSON style modal into a relational database. You CAN do it. But the tools and query language will make it much harder to work with. Not to mention lack of indexes on individual fields.
    - jeffdavis 14y ago
      People avoid introducing new data stores because it adds complexity and it's harder to do queries across data sets. Jamming different data models together in one system is a very viable strategy. Postgres supports functional indexes, so indexing individual fields within a JSON document is already possible. If it's not easy now it will be easy soon. Remember XML databases? They became extremely marginalized when relational systems started adding basic support.

vph 14y ago

>For my use case I do a single query to fetch my self contained User object which would need 30+ queries if I was using a relational database. This can't possibly be right. The 30+ SQL queries would have provided additional information that your 1 NoSQL query doesn't.