The greatest benefit of NoSQL databases is no fixed schema. This is also one of its greatest drawbacks. Data integrity has to be enforced somewhere and the best place for this is the data store. You could do it in the application layer using models and classes but a data store is likely to support more than one application so you now have to keep the distributed models aligned. You also end up writing more code to deal with documents that meet an older version of the model.
NoSQL documents are great when they can be read atomically and contain all the data you need, but access is slow and expensive if you need to do aggregation or go across documents. E.g. a document contains the customer delivery address, order date and a collection of item lines. Great to return the order information to a client portal. Not so great if you need to summarise sales by product group, month and region. You either write all the data to a second document (data duplication) or eat the cost of the aggregation.
One really good use of NoSQL is to quickly write the atomic data away in a structural format for later processing where high volumes might cause locking issues for a RDBMS. An example would be a ticket booking site where concert tickets go on sale at 9am and 50,000 orders are being made concurrently. These orders are the read into the SQL database from a message queue.
Another use is to reverse the process. Extract historic data from expensive live storage into documents and cold storage. You can then delete the historic data from the SQL tables.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The greatest benefit of NoSQL databases is no fixed schema. This is also one of its greatest drawbacks. Data integrity has to be enforced somewhere and the best place for this is the data store. You could do it in the application layer using models and classes but a data store is likely to support more than one application so you now have to keep the distributed models aligned. You also end up writing more code to deal with documents that meet an older version of the model.
NoSQL documents are great when they can be read atomically and contain all the data you need, but access is slow and expensive if you need to do aggregation or go across documents. E.g. a document contains the customer delivery address, order date and a collection of item lines. Great to return the order information to a client portal. Not so great if you need to summarise sales by product group, month and region. You either write all the data to a second document (data duplication) or eat the cost of the aggregation.
One really good use of NoSQL is to quickly write the atomic data away in a structural format for later processing where high volumes might cause locking issues for a RDBMS. An example would be a ticket booking site where concert tickets go on sale at 9am and 50,000 orders are being made concurrently. These orders are the read into the SQL database from a message queue.
Another use is to reverse the process. Extract historic data from expensive live storage into documents and cold storage. You can then delete the historic data from the SQL tables.