It's not about NoSQL vs SQL, it's about BASE vs ACID.
Scalable has to be broken down into its constituents:
Read scaling = handle higher volumes of read operations
Write scaling = handle higher volumes of write operations
ACID-compliant databases (like traditional RDBMS's) can scale reads. They are not inherently less efficient than NoSQL databases ...
noSQL databases give up a massive amount of functionality that a SQL database gives you by it's very nature.
Things like automatic enforcement of referential integrity, transactions, etc. These are all things that are very handy to have for some problems, and which require some interesting techniques to scale outside of a single server (think about what ...
When he reviewed the database schema he stated that all foreign keys and other such constraints should be removed as this is business logic and should be applied within the business layer.
Then he's an idiot, and some excerpt from your codebase is likely to end up on The Daily WTF someday. You're absolutely right that his approach doesn't make sense, and ...
Sorry to add another answer but none of the answers here are very satisfactory. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases).
Update (July 2020)
Every now and then this answer gets a vote and I get a pang of guilt because I've felt for a while it has grown into a ...
Generally speaking, if your workflow is a perfect match for relational database queries, you'll find relational databases to be the most efficient approach. Its kind of tautological, but its true.
The claim that many NoSQL advocates would make is that many workflows were actually massaged into a relational form, and would have been more effective before ...
While I agree with your premise that NoSQL is not a panacea for all database woes, I think you misunderstand one key point.
In NoSQL database you have only one criterion you can search for effectively - the key.
This is clearly not true.
For example MongoDB supports indices. (from https://docs.mongodb.org/v3.0/core/indexes-introduction/)
Normalization in RDBMS allows you to leverage the strengths of the relational paradigm.
Denormalization in NoSQL allows you to leverage the strengths of the NoSQL paradigm.
RDBMS are great because they let you model unique structured entities (mutable or not) and their relationships with one another. This means it's very easy to work ...
If you can represent your data in a form of a bunch of documents, MongoDB could be a good choice.
If you would rather imagine your data as a bunch of interconnected tables, MongoDB may not be a good choice.
Here are two examples which I find illustrative:
A few years ago, I created a blog engine. Its purpose is to host blog articles, and for ...
If you have data structures that are not clearly defined at the time when you make the system. I tend to keep user settings in nosql, for example. Another example was a system where the users needed to be able to add fields at runtime - very painful in an RDBMS and a breeze in NoSQL.
If your model structure is largely centered around one or few ...
Please consider this as an alternative. The previous two examples will both require that you make changes to the schema as the application's scope grows in addition the "custom_column" solution is difficult to extend and maintain. Eventually you'll end up with Custom_510 and then just imagine how awful this table will be to work with.
First let's use your ...
NoSQL is a rather vague term, since it basically covers all database systems which are not relational.
What you describe is a key-value store, which is a kind of database where a blob of data is stored under a key, and can be quickly looked up if you know the key. These databases are blazingly fast if you know the exact key, but as you say yourself, if you ...
It sounds like you made an essentially valid, short term data-store technical decision for your application - you chose to write a custom data store management tool.
You're sitting on a continuum, with options to move in either direction.
In the long term, you'll likely (almost, but not 100% certainly) find yourself running into trouble, and may be ...
How big a data?
There are two significant thresholds:
whole data fits in the RAM
whole index data fits in the RAM
With fast SSDs the first threshold became bit less of an issue, unless you have crazy high traffic.
One of the problem with scaling RDBMSes is that by design they are ACID, which means transactions and row level locks (or even table ...
I don't think that the size of data is the only factor. "Data model" is also a very important part.
E-Commerce catalog pages (Solr, ElasticSearch), web analytics data (Riak, Cassandra), stock prices (Redis), relationships connections in Social Networks (Neo4J, FleetDB) are just some examples when a NoSQL solution really shines.
IMHO, data model has more ...
I think you'd definitely like to look at this paper by Erik Meijer & Gavin Bierman, titled "Contrary to popular belief, SQL and NoSQL are really just two sides of the same coin". In short, it claims that mathematically speaking both approaches base on the same theory, but with some differences.
Couple of interesting differences are, from my opinion, ...
You have a number of options when representing a tree structure with MongoDB. Here are five "patterns" that you could apply (link to details at the end).
The Child References pattern stores each tree node in a document; in addition to the tree node, document stores in an array the id(s) of the node’s children.
The Parent References pattern stores each tree ...
Each technology has its advantages.
The advantages of relational databases is that the RDBMS does some things for you, like:
Enforcing referential integrity ( not allowing the insertion of an invoice detail if the invoice it belongs to doesn't exist)
Avoid redundancy: things are stored only once.
Complex queries can be done with a declarative language (SQL)...
Your assertions about relational databases are all true, up until the point where you have so much data you can't fit a copy of it on a single server anymore. Then you start running into all sorts of interesting problems. How do you split up your tables so most of your queries can run on a single server? How many copies of the data do you make? How do ...
Databases like MongoDB are great when you usually know where your data is(as opposed to needing to write several complicated queries). With Mongo, "related" data is either nested in the parent data or it has primary/foreign keys. This is great if, for example, you have Posts and Comments; generally, you aren't going to be displaying comments outside the ...
Snowman's answer correctly describes how SQL and NoSQL differ in their data structures and how these are accessed. However, a probably even more important difference is their respective problem domain.
NoSQL is not a successor of SQL. Rather, the various branches of NoSQL sacrifice some qualities of SQL in order to be better at others. The CAP theorem ...
The answer to this was ANSI SQL.
Although initial adoption was hard, especially for databases like Oracle, many of them now allow the ANSI standard.
For example Oracle started allowing that format in 9i (see http://allthingsoracle.com/ansi-sql/)
Also - PostgreSQL prides itself in standards compliance. Its SQL implementation strongly conforms to the ANSI-...
If you use Cassandra and need to emulate a lot of JOIN's, then you are doing it wrong. The reason for such a data model is usually that you are following the habit you learned from relational databases and normalize your data as much as possible. This leads to data getting spread out over many tables. This is a bad idea in Cassandra, because you have no ...
Most proponents of NoSQL overstate the scaling/performance problem.
This is admittedly an oversimplified point of view, but one of the big reasons that NoSQL is popular is because Google uses it. If Google uses it, then it must be good. But Google has enormous data requirements. Internet search notwithstanding, their source control repository is so large ...
Does using a NoSQL database give a boost to scalability even if you aren't sharding data? Well lets define scalability. If you are referring to scalability as database/backend systems are concerned, in that you have vertical and horizontal scaling where horizontal scaling IS sharding data then this becomes a trivial question because then the answer would be ...
Based on the requirements and architecture, there may be performance improvement options:
You may use indexed views(matrialized) To improve read
performance on RDBMS(Sql server) level. Basically, all you
need to do is: Create a regular view. Create a clustered index
on that view.
Using a cashing mechanism in application level will improve
performance. If ...
There is no such thing as NoSQL. There is a myriad of new database technologies grouped under that label, and they all work completely different.
But when you are talking about document-oriented, schemaless databases like MongoDB, which are one subset of NoSQL, then yes, these are often more suitable for modeling object-oriented hierarchies than relational ...
No startup has ever written the first version of their software with this kind of scalability in mind.
Facebook started out in PHP, and wrote a cross-compiler to convert their PHP code to C++ to reduce the number of servers they need by 50%. Twitter made major architectural changes, and got a 3X improvement in speed.
In both cases, they started out with ...
The key word in here to understand where your team is coming from is "microservices". It would be worth reading up on that concept first, particularly for the following information:
How should data be stored?
How are they designed to scale?
As with any relatively new way to do things (and 5-10 years is relatively new when it comes to ...
Here's my theories:
It's new and it's shiny. Look at me!
Facebook/google/twitter/whoever use it, therefore it must be good.
Data modelling (properly) is hard. A lot of developers haven't learnt that skill.
On the surface it sounds great. Simple, free, scalable. Plus I don't have to learn SQL!
People don't have a good understanding of ACID.