Direct Deposit Table Structure

Question

Post reply

Direct Deposit Table Structure

falcon00

SSC Veteran

Points: 241
More actions
June 22, 2010 at 2:27 pm

#224128

I am trying to decide on what would be the best table structure for implementing a Direct Deposit application where users are allowed to input up to 3 different bank accounts where their payrolls should go and also the ability to change existing. Each time a user submits a direct deposit form it has to be digitally signed and only then submitted to HR, and also the ability to save a draft.
Any thoughts and ideas are appreciated.
Thanks!

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

PaulB-TheOneAndOnly SSC Guru Points: 66772 More actions · Answer 1

In this particular case I'll probably go with a denormalized solution - single table.

_____________________________________
Pablo (Paul) Berzukov

Author of Understanding Database Administration available at Amazon and other bookstores.

Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

Ray K SSC-Dedicated Points: 31164 More actions · Answer 2

PaulB-TheOneAndOnly (6/23/2010)
In this particular case I'll probably go with a denormalized solution - single table.

Just curious: why single table? When I first read the question, my initial thought was to build a table for each account, and set up a foreign key relationship from a single user table.

I'm not trying to dispute, I'm just wondering (and trying to learn). (For all I know, your reasoning may be better than mine.)

+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/

falcon00 SSC Veteran Points: 241 More actions · Answer 3

Single table was my initial thought as well. Have a EmployeeID foreign key in the DirectDeposits table to join to Employees table.

But at the same time I thought about having two tables. One will store the Direct Deposit Requests and it's type (New, Change), and the other table would store the Bank Accounts (Bank, Routing #, etc.) per each request.

PaulB-TheOneAndOnly SSC Guru Points: 66772 More actions · Answer 4

Ray K (6/23/2010)
PaulB-TheOneAndOnly (6/23/2010)
In this particular case I'll probably go with a denormalized solution - single table.
Just curious: why single table? When I first read the question, my initial thought was to build a table for each account

Ray, ER modeling will prevent to create a table per each "account" - the basic idea is to preserve the integrity of entities, by implementing a table per account such integrity will be destroyed.

_____________________________________
Pablo (Paul) Berzukov

Author of Understanding Database Administration available at Amazon and other bookstores.

Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.