MongoDB History • Hacker News Board

Re: MongoDB History

#71

Post by jd_mongodb » Wed, Sep 09, 2020, 7:52 PM UTC

hodgesrm wrote: post #56

jd_mongodb wrote: post #53

Earlier quoted context omitted.

you can use JSON schema to lockdown you schemas like SQL but few developers choose do that as they prefer the flexibility that MongoDB offers. Changes in the schema are almost always due to upstream changes so the schema is a follower rather than a leader. Encoding your business logic in the database schema is rarely a good idea.

> Encoding your business logic in the database schema is rarely a good idea. If by this you mean not defining tables with explicit columns in general I would disagree. It's one of the most effective ways to get speed in analytic applications because it optimizes compression. And in OLTP applications it's the best way to ensure consistency of data. But perhaps you were referring to a narrower scope like just JSON & up…

No typing is great whether its BSON types in MongoDB or column types in RDBMS. Anything past that generally gets in the way of flexibility to respond to new business requirements. Business changes rarely originate at the schema level so its a bad place to encode business semantics.

Re: MongoDB History

#72

Post by hodgesrm » Wed, Sep 09, 2020, 11:43 PM UTC

jd_mongodb wrote: post #71

hodgesrm wrote: post #56

Earlier quoted context omitted.

> Encoding your business logic in the database schema is rarely a good idea. If by this you mean not defining tables with explicit columns in general I would disagree. It's one of the most effective ways to get speed in analytic applications because it optimizes compression. And in OLTP applications it's the best way to ensure consistency of data. But perhaps you were referring to a narrower scope like just JSON & up…

No typing is great whether its BSON types in MongoDB or column types in RDBMS. Anything past that generally gets in the way of flexibility to respond to new business requirements. Business changes rarely originate at the schema level so its a bad place to encode business semantics.

This just isn't true for a lot of use cases. If your requirement is to get low latency response on large data sets you need to cluster data carefully and compress it to reduce I/O. That's why data warehouses use column storage and strong typing.

Compressed storage size for uniform datatypes can be phenomenally efficient. I've seen 10,000x size reduction in ideal cases like monotonically varying integers stored using double delta codec + ZSTD compression.

Re: MongoDB History

#73

Post by manigandham » Thu, Sep 10, 2020, 12:11 AM UTC

jd_mongodb wrote: post #71

hodgesrm wrote: post #56

Earlier quoted context omitted.

> Encoding your business logic in the database schema is rarely a good idea. If by this you mean not defining tables with explicit columns in general I would disagree. It's one of the most effective ways to get speed in analytic applications because it optimizes compression. And in OLTP applications it's the best way to ensure consistency of data. But perhaps you were referring to a narrower scope like just JSON & up…

No typing is great whether its BSON types in MongoDB or column types in RDBMS. Anything past that generally gets in the way of flexibility to respond to new business requirements. Business changes rarely originate at the schema level so its a bad place to encode business semantics.

There's a vast difference between record shape and property types vs business logic.

Storing a record with strong typing does not get in the way of business, and in fact it often helps by maintaining data consistency and integrity.

Re: MongoDB History

#74

Post by NegativeLatency » Thu, Sep 10, 2020, 3:34 PM UTC

jd_mongodb wrote: post #68

NegativeLatency wrote: post #67

Earlier quoted context omitted.

I recently worked for a company where a different popular JSON document database was in fact forced down my throat. I proved that a regular database would be orders of magnitude faster with a real example on real data and while the project/product was canceled for marketing/sales reasons. Until it was canceled we were told by multiple levels of "technical" managers to use the worse database because of unknown reasons…

Technology selection is a black art in many companies. Sounds like people were open to listening to the opinion of a developer in your case. Often-times the selection heuristic is habit or history. The right companies will pay more attention to reasoned arguments of their own developers.

The wild part about it was that they were trying to use elastic search for relational queries because some manager thought it would be faster than a relational db. (It was about 60x slower)