3 ms·

Faster ? NO. In my use case I have one domain object with 30 embedded relationships. MongoDB: one request. SQL: 30 joins. Durable ? NO. It is trivial to distri

Faster ? NO. In my use case I have one domain object with 30 embedded relationships. MongoDB: one request. SQL: 30 joins. Durable ? NO. It is trivial to distribute data between multiple nodes using MongoDB and have writes be on some or all of them. I have yet to see a clustering SQL system that makes the process as simple as any NoSQL database. Fewer application errors ? Well this just makes no sense. Why would a database be causing application errors ? Either the fetch/store request fails or it doesn't. Lower TCO ? NO. MongoDB has an order of magnitude less TCO than any database I've used. Period. It is trivial to cluster, shard, deploy, manage and being schema-less there are no migrations to worry about. Ease of use is one of the big reasons why MongoDB is popular right now.

jeremyjh 14y ago
I don't think you understood him. There would not be many joins. You can use an RDBMS as a document database by storing documents in a single column, with key values in another column. For example, storing JSON in a text field (Postgres also has a native json type now as well I belive). You'd also want an Indexes table. Another approach that will also work well is to use a document model, you might have three tables, one of which has columns like (key, name, value) - all your data is in that table. Reddit uses something like this approach based on previous Hack News discussions.
- taligent 14y ago
  But you are talking more about key/value model. Which I see as a different use case to document model. And PostgreSQL HSTORE seems like a bit of a hack to me. It has a ridiculously complex syntax and still not sure how it handles querying other data types e.g. dates.
  - zrail 14y ago
    HSTORE stores values as strings, so in your query you'd have to cast to a date, or whatever type you're wanting to get out of it. The thing is, an RDBMS really is a superset of most of the other data models floating out there.. Entity-attribute-value, Document, plain key-value, whatever. Your every day ordinary RDBMS can do it, with transactions, durability, ease of administration, whatever. When you use a NoSQL data storage system you're explicitly trading off one or more of the capabilities of an RDBMS to get some other benefit. The one thing that Postgres isn't good at, as far as I know, is a graph-like data structure.
deleted 14y ago
[deleted]

jeremyjh 14y ago

I don't think you understood him. There would not be many joins. You can use an RDBMS as a document database by storing documents in a single column, with key values in another column. For example, storing JSON in a text field (Postgres also has a native json type now as well I belive). You'd also want an Indexes table. Another approach that will also work well is to use a document model, you might have three tables, one of which has columns like (key, name, value) - all your data is in that table. Reddit uses something like this approach based on previous Hack News discussions.

taligent 14y ago
But you are talking more about key/value model. Which I see as a different use case to document model. And PostgreSQL HSTORE seems like a bit of a hack to me. It has a ridiculously complex syntax and still not sure how it handles querying other data types e.g. dates.
- zrail 14y ago
  HSTORE stores values as strings, so in your query you'd have to cast to a date, or whatever type you're wanting to get out of it. The thing is, an RDBMS really is a superset of most of the other data models floating out there.. Entity-attribute-value, Document, plain key-value, whatever. Your every day ordinary RDBMS can do it, with transactions, durability, ease of administration, whatever. When you use a NoSQL data storage system you're explicitly trading off one or more of the capabilities of an RDBMS to get some other benefit. The one thing that Postgres isn't good at, as far as I know, is a graph-like data structure.

deleted 14y ago

[deleted]