Which one is better?
Who want their shit unstructured? SQL all the way
Dosen't matter it's all coorpo gabo
>>79696336THIS
>>79696299both
>>79696299Redpill me on NoSQL. Why is it better? Where does it leave SQL in the dust? And where vice versa?
>>79696336fpbpNoSQL is a meme
>>79696735when you have no idae what you are doing while prototryping, its faster to add a field to a json than changing tables while keeping normalization
>>79696299Most of the time your shit is going to be relational even if it is not obvious at first. If you went NoSQL, you will now have to deal with the consequences and need to hack on relational access to fix that mistake.It's better to always start SQL and learn what makes sense to carve out into NoSQL.
>>79696735if all you need is a big dumb flat table nosql is fine
>>79696807>logo implies hyper interconnected mesh of data>it's just fucking jsonwhy?
>>79696299Sql makes my head hurt so I prefer NoSQL
>>79697123I mean, that is valid reason, but it seems NoSQL would make your head hurt much more in the long run. Doesn't it?
>>79696299Depends entirely on your use case.
nosql is better for things that require graphs. I should have used a graph database like Neo4j for my project but insisted on learning SQL because it's something everyone has to learn. It's also better for unstructured data like metadata or exif data.Imagine trying to store these in a SQL database... LOL. I would cry. You would need to write so much
every rdbms supports json types now which obsolesce nosql
>>79696299If you were a serious professional you would know that each one has its uses, and fort his reason you have to know when to use one or the other.The problem is that in many cases dumb frontend people will use nosql because they don't understand how to design relational databases.
>>79696299Asking this question means you don't understand the point of NoSQL.Modern business applications past a certain scale usually benefit from a polyglot database approach, in terms of scalability. Hence, using non-relational databases for those portions of your application which are non-relational can help you scale larger faster and cheaper.The real question is whether Datalog is better than SQL.
>>79696299SQL. NoSQL is a disaster.
>>79696299If it's even a question, pick Postgres, it's a best in class general purpose database.If you very specific access patterns and storage needs in a way Postgres cannot efficiently do, you will reach for the specialized tool whether it's NoSQL or whatever else, even a fucking filesystem.TL;DR: Right tool, right job, and Postgres is almost always the right starting point.
>>79696826graph does relations better than rdbms
>>79696299SQL for everything that can be efficiently stored in a relational database, which should be most of your data.NoSQL for problems most of us will never have because none of us deal with quadrillions of datasets.
>sqlcomplex queries and relations required>nosqlsimple queries
>>79696299Use the right tool for the job.>Redis and other key-value databases for caches and common operations like authentication.>SQL for structured data (aka 99% of all use cases).>Neo4j and other graph databases for, you guessed it, graph algorithms.>MongoDB and other document databases for prototyping and nothing else. Document databases are dogs hit in production.t. software architect @ Fortune 500I’ve never seen a Neo4j project fail, because people only use it when they need it. But key-value stores and document databases are overused. If your data is more complex than a single value per ID, just use SQL.
>>79696879Because it’s a string rather than a table with primary keys, data types associated to each column, etc. That’s the primary draw I can gather about using NoSQL over SQL. To change your data model is as easy as changing the key-value pair and updating the encoding/decoding steps.
