to load or not to load

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

hey all,

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?

thanks,
rodchar
 
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?
Click to expand...

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.
 
well an employee consists of several tables in the back-end database. an
employee could have multiple education entries (education table), an employee
could be assigned multiple items such as a laptop, pda, cel phone (equipment
table), there's about 8 of these kinds of tables.

when a user selects an employee to work with would you go ahead and get all
this information or would you just get some of it and then load the rest as
needed?
 
well an employee consists of several tables in the back-end database. an
employee could have multiple education entries (education table), an
employee
could be assigned multiple items such as a laptop, pda, cel phone
(equipment
table), there's about 8 of these kinds of tables.
OK.

when a user selects an employee to work with would you go ahead and get
all
this information or would you just get some of it and then load the rest
as
needed?
Click to expand...

I certainly wouldn't *go ahead and* do anything, I'd probably just *do*
it... ;-)

I guess it would be a balance between amount of data sent across the wire
and numbers of round-trips to the server and back.

However, my general rule of thumb is that lots of little server hits give
much better performance in a multi-user system than a few big server hits.
 
Back
Top