so, I'm currently developing a feature for a website of mine, which aims to gather a set of financial data from the user so the user can start and take care of a budget, as well as the website offering some budgeting advice and offer some finance charts.
The data is supposed to be used like this:
- Users have to enter a set of a few "base" expenses or incomes, being groceries, salary etc.
- Additionally, the user will be offered the possiblity to offer as much free fields as he/she wants, which basically just consist of a name, type (income/expense) and value.
- There is not much data processing to be done, all my application will use is a accumulated number of total cashflow. The rest of the data is queried from DB, and directly forwarded to the UI
- The data can be updated at any time
Personally, I have only worked with regular relational databases before, except for Azure TableStorage. But besides that, barely any practical NoSql knowledge. However, I roughly know the differences, advantages and disadvantages. In this case I thought this was a perfect fit for a NoSql database, because:
- There's no complex or rigid relation to be held here
- The data is (partly) schemaless and needs to be extensible
- This is potentially an operation that is executed a lot
However, after talking to a few people, they still suggested to use SQL for this. The way to do this is quite clear to me, I'd probably have a table with the type (income/expense), the name of the item, the value, and an indication to map this to a given user.
Okay, perfectly valid. However, I thought this is very much a good use case of NoSQL. This is not the first time I thought I hit a good use case for a NoSQL usage, just to find out in the end (when talking to people who definitely know better) that a traditional relational database is the way to go.
So, what boxes would my use case have had to tick in addition to this to be considered a good NoSQL use case?