"rodchar" <ro*****@discussions.microsoft.comwrote in message
news:DA**********************************@microsof t.com...
i have an employee master table that i've broken up into many tables using
normalization and what made logical sense (i.e. Education table, Equipment
table, military history table, etc. i think there may be about 8 tables).
What i was wondering was when a user selects an employee to modify would i
load all the tables up for that employee or would i just load the most
used
values?
My immediate reaction is: why would you load any tables at all?
The key here is your phrase "when a user selects an employee" - *an*
employee - one - singular. You're working with one employee - what benefit
is there in loading the entire set of employee tables? What if you have ten
employees, or a hundred, or a thousand? A few years ago, I wrote an employee
system for a global company with over 150,000 employees worldwide... You get
the picture...?
Perhaps an object-orientated approach would be better?
I'd almost certainly be looking at a data abstraction layer and a business
logic layer.
Create an Employee class with properties for a single employee, methods to
insert, select, update and delete an individual employee etc...
Instantiate the Employee class, fetch a single employee object and work with
that.