I'm busy looking at a number of projects and trying to decide whether I should be building them with SQL or noSQL databases. Both seem to have advantages and disadvantages - SQL is more strict, but has powerful querying. noSQL seems less strict, growing with your application, but does it query as well at scale?
Is the best solution, perhaps, to build whichever you're most comfortable with while developing an MVP and then changing it later on? Or is it better to plan for growth from day one?
okay ... again without any idea about your project i would still recommend nosql. Since in future you might scale up which is more viable option and rather changing your database then you should start with nosql in the beginning. However if you are in Learning Stage then you got to work in both for experience.
it depends on what is important to you , use the right for the right task mongodb is new girl on the block , very good for aggregated to queries which is very important for mobile (one time trip o server to get all the data ,once) , if your doing anything JS based ,absolutely use mongo , only case i prefer Sql , if you would perform micro update ,that other endpoint relay , say for keeping track of transaction across several file , sql is very well suited for you, but you do without micro updates propagating everything , mongo is a better choice
Got it on Internet.
Thanks for invite and sorry for the long post ...
Without knowing a lot about your projects it is hard to be specific. However if you are at the ideas stage and are looking to create MVPs then use the technologies you know and are most comfortable with - these can always change if the project(s) succeed. However, if you are working for an established company and have enough resources, know-how and time then you can go down the route of investigating the best long term solution - starting with some proofs of concept, for instance.
A key distinguishing feature between relational and current NoSQL products centers around the SQL Join. With relational databases the objective is to abstract objects into groups of very similar data (tables) avoiding data duplication as much as possible (normalisation) The objects are then re-constituted from 'related' data (hence relational) from the tables.
For instance, modelling a company, we could have tables for People, Roles, Departments, etc Roles will have a link to People, so we would have to 'join' Roles and People to find a list of people that occupy a role.
NoSQL systems approach things differently. The basic principle is that instead of breaking up objects to then re-constitute them using 'joins', why not just store all related data inside one structure and avoid the 'join' altogether ?
Most of the advantages and disadvantages stem from this difference in philosophy (approach) For instance, it is easy to shard NoSQL systems since the data for any one object is (there are exceptions) already in one place. Whereas can you imagine the technical difficulty involved in trying to 'sql join' tables that are spread accross several servers (possibly in different parts of the world) ?
ACID properties are often mentioned. Relationals provide ACID as a matter of course, but noSQL systems are evolving as well - for instance, MongoDB now provides ACID properties on a per document basis. Even so, using so called 'micro-arhitecture' approaches, this becomes less important.
As for querying, this shouldn't be a deciding factor as many NoSQL systems now provide their own querying language. The only problem I see is that there is currently no standard for NoSQL query languages. So if you chose CouchBase, you'd have to use their N1QL languages which is quite different from the querying language offered by MongoDB for instance.
Note: I have mentioned only document stores so far, but there are other types of NoSQL databases as well. Specifically, you may also want to consider wide column stores like Cassandra, key-values stores like Redis, etc It all depends on the data you are capturing and what you want to do with it.