Both SQL or NoSQL can store and retrieve data of this kind, and both technologies can be made to do this job.
The major differences are elsewhere: in a nutshell, transactions and guaranteed consistency for SQL versus high performance for readers for NoSQL.
In your precise situation SQL, with its support for transactions, will ensure that viewers will see a composite product when all sub-products have been successfully stored.
In most real-life situations, however, the chance of a viewer seeing a partially-committed product on a NoSQL system is so slim as to be irrelevant: future reads of the product will be correct.
manpreet![Tuteehub forum best answer]()
Best Answer
2 years ago
I face the following problem. The target is to develop a DB to store the following schema:
You have
PRODUCTSthat can be composed of bothPRIMARY_PRODUCTSand also otherPRODUCTS.My first question is to know which one of SQL DB or NoSQL technology would be recommended for this? I don't really know well NoSQL and I am not sure it is worth spending time investigating if the whole concept is not suited with the pb. If NoSQL is worth looking at, which version is recommended? I was looking at Cassandra but there are so many types that the universe is quite big.
If NoSQL is not suited for this, so we need to revert to SQL. Do you thing that
hierarchyIdis suited?