Database design for Financial software

Best Practice :

I am developing an application which will be used by people to file their income tax returns. As the rules of income tax are dynamic there will be changes in the database structure and UI forms at least  once in a year. These changes will be in calculation, data entry forms and database tables.

I would like to know what will be best way to incorporate these changes without much disruption to the application year-on-year. Will it be advisable to use different database instance for every year or make the changes in the same database. Or there is any other better way to handle this.  

Thank you
JsandeepAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

kaTaVasijaCommented:
Personally I would take a chance to handle as much  changing requirements as possible in one place. Since it is inevitable leaving database unchanged, firstly I would try to settle user interface configuration in a db too.  If your database provide a procedural extension (e.g. Oracle PL/SQL or T-SQL, PostgreSQL..) it is worth trying to design UI in such a way that all changes are handled at a database level. For instance, Oracle forms allow to quickly build user interface universal lists, blanks , which configuration is stored in a database tables set. If one doesn't have an opportunity to use auto configured user interface, one would try to build it for himself? For example an abstract universal form has a number of array controls. This form on load fills this arrays of controls with data
May be user interface could be based on db views , just simple as that ?
The opposite variant is to give all logic to UI and give database only data. In this case the UI configuration might define which tables to read and what to do, but i think db is more comfortable to work with logic, that depends on time (e.g. validity of business entity is in two fields: history_from, history_to)
I've had similar but simpler experience with financial reports and we had to change it once a half a year. In the beginnig all the stuff was held by UI, as reports were easy , but as logic of the reports got more complicated, we've come to the reports, which every field is a function call from db. So our report forms are predictable, and if there is a need for new field we put it on the form and write another function for it at database level...
That's an interesting question and I am looking forward to hearing from the experts too.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JsandeepAuthor Commented:
While we are waiting for the inputs from other experts. Does making separate databases is an acceptable alternative or it is a strict no-no.
0
Ray PaseurCommented:
No points for this, please, because it is not an answer to your question, just an attempt to point out the magnitude of what you're trying to do, and the power of your major competitors.

How big must your program be to cover the tax code?  The code is thousands of pages long and changes every year.
http://taxfoundation.org/blog/how-many-words-are-tax-code

In the United States, one of the premiere tax preparation services is Intuit, authors of TurboTax.  Intuit has 8,500 employees and a market capitalization of $28,000,000,000.
https://en.wikipedia.org/wiki/Intuit

So database design is not really the central issue in an endeavor like this.  It's more an issue of how you might generate the public trust and the financial and political capital to be able to enter the marketplace
0
HuaMin ChenProblem resolverCommented:
I think you can still keep different year's data on the same schema, while you'll have year table to know which is the current year.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Databases

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.