5 ms·
Haven't seen a reason to use any type of NoSQL aside from a cache layer. Most Modern RDBMS have Json support if you still want to use a document approach for sp
by alunchbox 9y ago
Haven't seen a reason to use any type of NoSQL aside from a cache layer. Most Modern RDBMS have Json support if you still want to use a document approach for specific cases but overall Postgres and SQL Server are able to perform equally if not better then most recent NoSQL implementations (unless it's a really specific one off use case for reading)
just look at the nightmare MongoDB has created in most startups a year later.
- mysterydip 9y agoThe SQLite site says it better than I could: https://sqlite.org/whentouse.html https://sqlite.org/whentouse.html Personally I use NoSQL options for the "replacement of ad-hoc disk files" they mention on that page. Like many of the comments here, anything more advanced than that and I'm using a relational database.
- scarface74 9y agoI fell in love with Mongo when I first started using it 6 months ago - the whole NoSql thing appealed to me. Then I fell in love with Sql Server 2016's JSON support - the best of both worlds.
- plet 9y agoFor me, NoSQL works great when the structure of the data is unclear but you have a fixed identifier that you can key off. SQL when the structure is known and juggling multi-table transactions is not a big PITA. I'm not sure about the mongoDB nightmare, for me its done everything as the documentation claims it'll do.
- atomical 9y agoIf the structure of the data changes why wouldn't you modify the schema? Could you give an example of what you are talking about?
- deleted 9y ago[deleted]