CODEWITHSUNDEEP
databaserelational-databasedocument-oriented-db
hllau
hllau

Reputation: 10549

Document-oriented database or Relational database, how could I choose?

I have been using MySQL and MsSQL quite a bit in the past. Now I am using MongoDB also and I see it very flexible in handling document which fields keep changing - very good for agile development.

As document-oriented database seems to be a lot more convenient for developers to use, and it is also faster in terms of read access, may I have some examples on which use cases would fit in either case better than the other?

Upvotes: 1

Views: 381

Answers (1)

Horus
Horus

Reputation: 1175

I work as a data engineer, and I have to work with document databases and classical RDBMS's; I have to do application code, ETL, and I have written custom wrappers that pull json from document databases and build full relational schemas to load the data for reporting purposes.

First, document database do offer good things for certain activites, and RDBMS's offer certain power that will be missing from document databases.

RDBMS's offer the ability to control your data very clearly, with rules, triggers, etc. Most document databases do not offer this and it is questionable if they should. The more rules that they follow, the more flexibility they lose, and that is their major gain.

One of the issues that you will run into with document datastores is that you have to carefully choose your top level entry point, or you will have to create multiple datastores, and remember, there are no join statements in most (ignoring tools that Google has recently written papers on).

I believe that data control should happen at the database layer, to prevent data corruption. Then again, I'm a data guy. Application, SEO, and business people will often disagree with this. As such, I accept and move on and try to make everything work together when the reporting people tell me what they need.

Upvotes: 1

Related Questions