Why choose Couch DB over Rational Database?
Choosing a correct database is very important in software development.
The relational database maintains ACID rules. Relational model requires relational database engine to manage writes in a special way. It locks the rows and table to maintain atomicity and consistency. Protecting referential integrity across the tables and rows increase locking time. Increase locking time means higher latency and slower application. Developers face some problems with the Relational database such as:
Object Relational Impedance Mismatch: When RDBMS is being served by an application program written in an object-oriented programming language, objects or class definitions need to be mapped to database tables defined by a relational schema. Misalignment layer of application objects to tables and rows is called Impedance mismatch.
As an example, below are the schema definitions:
Below is the application code:
In this example, object foo contains field Id and colours (which is a bunch of strings). To store this into the database we need to create 3 tables.
- Main object
- Colour information
- Relation between color and main object
These forces the developer to write a mapping layer such as Entity Framework or ado.net to translate the objects in memory and what is saved in the database.
Many of the developers use object-oriented languages in development. Objects are not rows and tables. All objects are not uniform. Mapping those objects into rows can be painful.
Couch DB is schema-less. There is no relation between a collection of objects. A developer can store any type of document. The documents can be flat and simple or as complex as the application requires.
Couch DB document for “Foo”:
Scalability Issues: Scaling out and replicating data to other servers need to increase the lock. Relational database tries to be consistent and increase the locking time and as result application gets slower.
Replication is one of the features in couch DB. Replication takes advantage of clustering to achieve scalability. We just need to mention the source and destination database. Couch Db will handle to replicate the data into a destination. This can also be achieved through a REST call. It should be a POST request to the endpoint “_replicate” with the source and destination servers specified in the body of the request.
|RDBMS With MS SQL SERVER||NO SQL WITH COUCHDB|
|Define table||No schema|
|Rows and Columns||Document|
|Dynamic Query||Predefined query|
|Constraints, Triggers, SPS||Validations, show & List Functions|
B-trees append data only to the database file that keeps the B-tree on disk and grows at the end. B-tree delivers fast searches, inserts, and deletes.
Couch DB features on the server-side document validation and on the fly document transformation. Although a document is stored in JSON, the document can be served as XML or CSV.
Architecture OF Couch DB: