CODEWITHSUNDEEP
sqldatabasetransactionsfinancenosql
fadeltd
fadeltd

Reputation: 349

Why you should not use nosql for financial transaction

I heard from a speaker at a Hackaton event organized by a bank that you should not use nosql for financial transaction for security reasons. But I have no idea what he's saying. I have been looking for an answer as to why I should not use nosql database in my application.

What are the pros and cons of nosql, and what are the pros and cons about sql databases for financial transaction?

Now, I'm building an application for shop cashier, where the cashier will use this app to store transactions, receive orders, and receive payments with Cash or Credit Card.

What is the best possible approach for this project's API? SQL or NoSQL, and why?

Upvotes: 10

Views: 14134

Answers (4)

Apurva Singh
Apurva Singh

Reputation: 5000

In scenario of making payments, transferring money between accounts, stock market transactions, we need strict ACID. Even simple things like, I want to read my account balance ($100) and withdraw $90, but before I can withdraw, my wife withdraws $80. So bank ends up with negative balance in my account which probably violates some rule that bank disallows negative balance.
So what do we do about this? Relational databases provide excellent ACID and database locking tools. One can hack around in MongoDB too, but hack is still a hack. MongoDB is coming up with ACID etc, but in a distributed shards based system with no strong consistency, I would stay away from it.
Finally, in era of micro services architecture on server side apps, we have database per service (not dedicated physical I mean, but logically a db per service). So it is straightforward to have two databases; a MongoDB and a Relational. Use relational for transactional stuff which will be barely 10% of use cases. Use MongoDB for the remainder use cases like, browsing data, images, reading reviews, content, accounts history etc etc. So since most uses cases over 90%+ will be MongoDB based, so still achieve the goal of high scalability.

Upvotes: 2

ahoxha
ahoxha

Reputation: 1938

SQL and NoSQL databases are not interchangeable. There's no silver bullet database technology. You should consider pros and cons when choosing what database technology you want to use for your project.

Short answer: If you need to process transactions, your data can nicely be arranged in relational entities then use SQL. If you need to handle large volumes of semi-structured or unstructured data, and need horizontal scalability, then use NoSQL.

If you want to read more about differences between SQL and NoSQL click here or here.

Some insight on when to use SQL or NoSQL can be found here.

Upvotes: 6

Cross
Cross

Reputation: 1454

AS explained by @A2H, the SQL and NoSQL depends on your requirements, saying that NoSQL is not secure is not accurate, this is like saying that SQL is not scalable... which is not true either.

Now, for a financial application you will have some non-functional requirements that I can list below:

  • Secure at file level: if someone has access to the database file will they be able to use this to load the information somewhere else? for example, in SQL Server the login information about the db is included in the files, therefore copying the files without the password will make hard for hackers to steal information.
  • Scalable: How much,are we talking about? some millions records? Scalable in what sense, do you require to do distributed queries or just localized databases depending on the region and central tables for accounts info? or are you planning to create an application that will receive tons of records per second (like forex information) and therefore you need something to ingest tons of records and analyse results? in that case maybe NoSQL is for you.
  • Transaction (ACID) complaint: Are you handling transactions (like the type of debit this credit this other?) then you might need to use something like Djondb or traditional RDBMS, both support transactions.
  • Flexible schemas: You need a flexible schema that can adapts to your frequent changes without having to redesign your database and updating previous records? NoSQL is good at this.

the list will continue... but I think you get the idea...

Saying that NoSQL is un-secure is an overstatement, as any other generalisation.

Upvotes: 11

鄭有維
鄭有維

Reputation: 265

Maybe I think one of the reasons is "nosql doesn't support ACID"

It's same means there is not transaction.

Maybe it can explain why no use nosql for "financial transation".

Upvotes: 0

Related Questions