Re^3: Imagination greater than reality?

I would not be surprised if it were significantly easier to write code for each state than to try to devise a set of tax tables.

Actually I would expect that maintaining 50 different sets of code would be significantly more effort than a single set of code with a DB, even if the code is significantly more complex to write in the first place. 50 different algorithms is a difficult thing to get one's brain around. If say some flaw is found in the Texas algorithm, then it could be a big problem figuring out which of the other 49 sets of code are affected.

Another factor can be just the on-going updates of the per state information. I doubt the OP is working with "sales tax" - that was just the first obvious "per state" idea that popped into my brain. There are companies who specialize in DB's and software to deal with the complex plethora of US tax laws. A long time ago I had a friend who was a salesperson for a company like that. What multi-state and multi-national companies do with this tax stuff is super complicated and worth "big bucks". For a number of reasons, "roll your own tax code" is not a good idea. My mention of this was just a "for instance, example", not anything deeper than that.

Back to the generic programming issues... Whatever it is that changes between the states, a solid program "product" will have a way to keep things "right" and "updated" past the first program release. As a dev engineer, I want to write new code that solves new problems. I can't do that if "my released product code" is not maintainable or extensible by somebody else.

I have no problem with the solutions to the OP's problem which address it directly - they look fine to me. My goal was to present another possible approach to the OP's problem.

One issue is "hey, its been 2 years, how do I know that this per state stuff is "up to date"? How does somebody get "notified" that something needs to change for Texas? As another issue, an OO paradigm seems like a good idea here. I would not put knowledge of the states into the stateObject. I would use some parameter like 'TX','AX','NTX'(North Texas) when creating the "StateObject" and give a clear error message comprehensible to the expected "user". The new StateObject looks into the DB and initializes its behavior based upon that. If Puerto Rico, PR ever becomes a state (which it probably won't), add another line to the DB. The testing code can make 50 different state objects and run the same data against those objects and compare results. A situation where the program starts and then is "customized" to a specific state is not as flexible of an approach.

From what I have read, the OP is proceeding with a solution that works for him. Fine. There is often "more than one right answer" here. My comment are for others who may follow with similar issues.

Comment on Re^3: Imagination greater than reality?

Replies are listed 'Best First'.
Re^4: Imagination greater than reality? by RonW (Parson) on Jul 19, 2017 at 20:08 UTC
I do agree that parameter-izing generic code is preferable to coding each case. I also know that, sometimes, it's clearer and cleaner to "code the cases". (And even then, I still try to parameter-ize a lot of the code into call-able functions.) Out of curiosity, I asked one of our IT department's database gurus if she knew anything - or knew anyone who knows - about tax rate databases. 2 of her colleagues at other companies do work with tax databases. She told me that they use a lot of "stored procedures" and triggers to calculate the applicable tax rate for a significant majority of the scenarios the databases cover. Their rational is that this greatly reduces the complexity and size of the databases. Also, that even if they had to deliver a database with no stored procedures, they would have to write similar code to generate the parameters to store in the "pure" database.	[reply]

Replies are listed 'Best First'.

Re^4: Imagination greater than reality?
by RonW (Parson) on Jul 19, 2017 at 20:08 UTC

I do agree that parameter-izing generic code is preferable to coding each case. I also know that, sometimes, it's clearer and cleaner to "code the cases". (And even then, I still try to parameter-ize a lot of the code into call-able functions.)

Out of curiosity, I asked one of our IT department's database gurus if she knew anything - or knew anyone who knows - about tax rate databases. 2 of her colleagues at other companies do work with tax databases. She told me that they use a lot of "stored procedures" and triggers to calculate the applicable tax rate for a significant majority of the scenarios the databases cover. Their rational is that this greatly reduces the complexity and size of the databases. Also, that even if they had to deliver a database with no stored procedures, they would have to write similar code to generate the parameters to store in the "pure" database.

[reply]