The relational database management system is a great innovation of the previous decade. The RDMBS enforces an ACID-based transaction processing and recovery system where A = Atomicity C = Concurrency I = Isolation and D = Durability.

Although the RDBMS supports an excellent query subsystem, there are some negative points of the RDBMS, such as:

1. Unwanted accumulation of redo log files. RDBMS provide a transaction commit and rollback facility to enable these ACID properties. These cause unnecessary overload.

2. Frequent creation of ADO/DAO/ODBC or JDBC connections on the server side to execute SQL commands. These SQL commands are used to transport user data from the Client to the Server. The SQL commands are namely Insert. Update and Delete. These 3 commands have an effect on the records inserted into the database, while Select only reads the records. One can easily see that client to server transport can also be done using FTP. However, transaction-oriented systems before the advent of AJAX prohibited the use of flat files or any other mode of client-to-server file transfer, requiring the exclusive use of SQL.

3. One of the other downsides to using SQL is the frequent creation of insert and update scripts used by SQL processors, which require elaborate syntax checking and parsing, more than is required to load data into the database. database, let’s just say using FTP or any other. another symbolic language.

Since the advent of XMLHTTPREQUEST, client-to-server transactions have been loaded asynchronously to the server using XML. If you had noticed, a client side Java script had no functions to load any data using flat files. This additional feature was achieved using AJAX (Asynchronous Java and XML).

When there are many users making a data change request in a database such as a rail reservation system, it is necessary to block users other than the active user from making changes until the first user completes the transaction. This is required, as the action performed by one user would affect another user. An example of the above is that the number of free seats on a train during a particular date will be affected by the number of simultaneous accesses to the database.

Now consider another transaction, such as a status update on a blog post. In this case, there is no need to guarantee high levels of concurrency by blocking the database from concurrent requests. a blog that does not require extensive blocking features. So if a blog uses an RDBMS on the backend to store messages and other status updates, it unnecessarily invokes the locking mechanism which creates performance bottlenecks.

All these negative points of the RDBMS have given way to the NOSQL movement. In a NOSQL system, the physical database does not support the RDBMS row and column format, so you avoid the overhead of writing detailed SQL statements such as Insert, Update, Delete. In Nosql, SQL statements written within RDMBS are replaced by object-oriented programs.