1

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:

  1. There's no complex or rigid relation to be held here
  2. The data is (partly) schemaless and needs to be extensible
  3. 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?

6
  • 3
    Possibly answered already over on SO: stackoverflow.com/questions/441441/… But I think the most important point is near the end of the top answer: " If you feel no pain using a RDBMS, stay with it. If you always have to work around your RDBMS to get your job done, a document oriented database might be worth a look." Oct 25 '20 at 16:17
  • 2
    Your data model seems like a reasonably good fit for a document database (nothing particular relational going on), but why deal with all of the subtle gotchas of a NoSQL database when you could just use a rock-solid relational DB like Postgres? No data is actually schema-less, the schema is just implicit or explicit. You can use a SQL DB for the 90% of data that easily fits a schema, and JSON-typed columns for the rest. Whether NoSQL makes sense probably depends more on other requirements than the schema, e.g. MongoDB is good for high write loads and sharding but useless for OLAP workloads.
    – amon
    Oct 25 '20 at 16:52
  • @amon Thanks. I suppose I'll stick to my RDBMS then. I think the thing that is very tempting to me with nosql databases is also the fact that development can be much quicker because less time needs to be spent on normalizing data and building up database relation models Oct 25 '20 at 17:34
  • I would suggest investing time in meeting your real needs for querying. I mean, at first sight, it might seem you don't need RDBM but if you are too biased by RDBMS it's likely your solutions at some point will be grounded as if your store was a relational one. The first time I implemented MongoDB I made some design assumptions based on false premises, as for example transactionality. Later new features made me sweat, mainly those involving relationships and data mining. I could not just say to the customer "I can't implement the dashboard due to MongoDB limitations".
    – Laiv
    Oct 26 '20 at 13:09
  • I took it forward, but I do recon. that with RDBMS it would have resulted in much simpler code. Take into account also if there's going to be anyone else mining the DB. Say operators maintaining (as a 3rd party service) the DB. If it's going to be used by other systems, etc.
    – Laiv
    Oct 26 '20 at 13:10
1

The most important thing to know about NoSQL databases is that there's no such thing as a NoSQL database: it's a term that refers to a number of distinct types of datastores that are not relational. Some even support SQL! (or some variant thereof.) It's a little unfortunate that the term has stuck since it just tells you what it isn't and not what it is.

The use cases for a graph database and a key-value database are quite different. Using a dynamo-style DB (e.g. Casandra) is different than using a document-db. Like any technology choice, each type of database has it's own advantages and disadvantages. In this case these differences are especially important because 'NoSQL' databases are highly optimized to do one-to-a-few specific things really well at the cost of doing other things poorly. A RDMBS is sort of a jack-of-all-trades and a NoSQL database is a one-trick-pony (by design.) It can make sense to use a NoSQL DB if you are playing to its strengths and its weaknesses are not relevant. This article is getting a little dated but I really like it as a primer on this subject:

Another thing to keep in mind is that with a lot of these databases, you really need to understand how the data will be used and design things around that. In a relational DB it's often the case (but not always) that we can focus on building a proper relational model and worry about how it will be used later. That approach can lead you to a bad place with NoSQL databases. If you are thinking in joins, you are probably going to have a rough time, except possibly with graph databases which, in some sense, take joins to a whole different level.

Having said all that, I don't see your use case as being a great candidate. The situation you describe seems to be easily doable in a RDBMS and, unless I misunderstand, you will still need a RDBMS for other reasons anyway. The extra complexity of a separate DB for such a small requirement doesn't seem to have enough payoff. The only caveat would be if your performance or scalability requirements cannot be met with a RDBMS but that seems unlikely here.

1

The first criteria to use in deciding SQL vs NoSQL would be is the data relational? I would argue a budget is relational. Second would be is there a consistent schema? I believe your schema is far more consistent than you think. I would use a SQL database. The other important question is performance, but anything user facing a SQL database will handle the load just fine for 99% of use cases.

Here is why I think you have a consistent schema and relational data. You have users (table) that have income (table) and expenses (different table). Those incomes and expenses can have types (table per or maybe one). Budgets are also based on a time span and it may make sense to have a table relating incomes and expenses to a budget, and users may want multiple budgets anyway so you now have a many to many relationship. Budgets also track planned vs actual expenses, which means even more tables and relationships.

Good NoSQL uses cases are rare. Performance and high availability are the big ones, at the extreme levels a NoSQL database handles key value and is more capable of 99.999+% availability than a SQL DB. Unstructured or semi-structured data is the other big one, which is typically logging or analytical data. Finally, big data applications work better in NoSQL, this also has a rule that if you have to ask if your application uses big data, you aren't using big data.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.