search

vicjohnson1213 / Budget-Manager-API

My own personal budget manager API.
0 stars 0 forks source link

Expand filing status option #2

Open sutartmelson opened 7 years ago

sutartmelson commented 7 years ago

A simple solution for the database might be to have one table per filing status per federal/state. This will results in only four tables for federal, but over 200 for state. Or just really big tables. I don't know enough about databases to know which is better.

Does this data even need to be in the database? What advantage does that have? All the data could be parsed and stored in a json object of the form rates.federal.filingStatus or rates.state.filingStatus or something along those lines.

Maybe add a filing status to the user table as well.

vicjohnson1213 commented 7 years ago

Big tables are always preferred over a bunch of small tables that will contain nearly identical data. Every one of those tables would need stored procedures to interact with them (so around 1000 stored procedures).

Having them all in json files seems like a good idea right now since rebuilding the app is so easy locally, but this turns into a bit of a pain when an app is in a production environment, where just changing the tax rates or such requires pushing code and rebuilding the API. If the data is just in the database you just have to run a script to update the rates or whatever and it's all done.

Let me think on how the db should be designed for something like this.