Should I be using mySQL or MongoDB [closed]

Question

There is alot of talk at the moment about NoSQL from my understanding Mongodb is one of them, to me the NoSQL seems that it is SQL just not in the same sense that we know mySQL.

Think of it this way, they both store data, one does it by a fixed database with so called limits while another stores data when it thinks it the best time to store data and supposable has not limits or very few.

However this is confusing to web developers who are making the switch or thinking about making the switch. In my case I work for a big teleco company and making a switch like this is something that needs to be really looked at, and we cant relay on something that has no physical being so to say.

Maybe I am not understanding the meaning of NoSQL, maybe I have the meaning correct.

I am in the process at the moment re-writing the whole CMS that we use, and would kinda be nice to know should I spend the time looking at noSQL or keep MySQL (which does not seem to have any issues that the moment)

We only have 5000 rows in the customer details and in the backup with have 14000, it gets backed up just incase the master table decides to screw up.

Answer 1

Are you being forced to select one or another? If not, why limit the potential solutions of solving your business requirements by having to do 'this' or having to do 'that'. I equate the workflow steps of software engineering to those of a doctor.

A doctor has to make a number of decisions to ensure the operation goes successfully. This includes diagnosis, determining the incision points, and selecting the required tools of their trade; scalpel, bone-saw, etc. to complete the operation. If you told the doctor that they could only do the operation with a crossbow, the end results won't work out well for the patient or the doctor (malpractice).

So stepping away from the clumsy analogy, here are a few reasons why I opt to use both, (using an online bookstore as an example):

• Book data such as ISBN, author name(s), dates published, etc. are stored in a RDBMS (let's say MySQL). By storing this type of data in MySQL I can run any number of queries to present to a user. For example, I can run a query returning you all books published by authors whose last name being with the letter Z, and a publish date of 2005, ordered by their ISBN descending. This type of data manipulation is critical when creating useful features for your company (or clients).

• Book assets, such as cover art are stored on the filesystem using a NoSQL solution. This solves two problems. First, I don't want voluminous data ballooning up my MySQL database (blobs) so I'll store this data on the filesystem. And secondly, a book's cover art has nothing to do with any of the actual book data (people really going to want all books with the color blue in their cover art?). And we simply cannot forgo a book's cover art, as it could make or break a sale when a user is browsing our online inventory.

In closing, my recommendation to you is to select any and all the tools you need to finish the operation successfully, and in a way which makes it easy to add new features in the future.