A little DB modeling... Preferred method... (1 Viewer)

[SodaJim]

Hello,

For some time now I've been creating small DB solutions to accomplish various tasks such as Scheduling, Track Training, Overtime tracking, Vacation Tracking etc, etc...

All of these work fine and some have been implemented for a couple of years now. All of the various DBs have been converted to Access 2K to correct any errors and to assure the same version/stability/functionality.

My question boils down to creating a master DB since the one common factor between all the applications is Employee Information. Which is the best approach to creating a Master DB, just import all the relevant tables from the other applications and create one BIG DB, link to all the other tables in the other DBs, or create an empty DB, if you, that just has a switchboard to allow my users to access the various applications...?

Lastly, I will mention that there are various queries/reports with some being a little complex!

And above all, I need to keep the system VERY easy to utilize!

Any thoughts and suggestions welcome...

Thank you,
Jim

 

[SodaJim]

Anyone with experience...?

Anybody willing to steer me in the right direction on this...?

 

[jjturner]

Offhand, I like the idea of an 'empty' db Switchboard solution, which I haven't attempted myself.

I'm managing:

• Admin db (employee ID's/reporting assignments, etc)
• Productivity and Volumes db (tracks and generates business unit stats down to emp level)
• Claims db (tracks accepted/rejected claims for the business unit, generates rpts)

...along with various other projects.

I don't see any benefit to clumping all of it together into 1 db. But like you, the extent of maintenance overhead is beginning to reach critical mass for me.

Unfortunately, that's about all the thoughts I can offer on the subject. I'd be interested to see what other ideas are out there.

Regards,
John

 

[Len Boorman]

Maybe you should look at att the different applications and then "normalise" the Data.

Suggest then that a solution would be to have one of the applications with the employee data in and then use this table within the other applications as a linked table.

Regards

Len B

 

[SodaJim]

So...

The best approach may be to develop a central DB on Employee Data and link tables within the other applications based on the required data from the Employee Data DB.

Everyone concur...

Thanks again!