So I want to know whether transaction based web applications can have no sql databases instead of my sql. Or is there a rule of thumb to use My sql, taking into care for standard compliance?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
So I want to know whether transaction based web applications can have no sql databases instead of my sql. Or is there a rule of thumb to use My sql, taking into care for standard compliance?
The first sentence of the OP (
...transaction based web applications...) in some sense answers the question. You would need a NoSQL implementation that does support transactions so that you can guarantee atomic updates across multiple data entries. A response to a comment seems to indicate that MongoDB is the DB under consideration. That does not seem to be a good choice for transactions.Unless there were some kind of add-on that provided ACID transaction support, then it would make some operations difficult. The obvious and overused example is debiting from one account and crediting another. If that couldn’t be done in a single transaction, then you would quite possibly be losing money (or creating money if you did the credit first ;).
I don’t know about “rules of thumb” for this question, but my suspicion is that you would find an easier time of it using a “traditional” database for a commerce-based system.