By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,318 Members | 2,116 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,318 IT Pros & Developers. It's quick & easy.

Multiple Lookup tables

P: n/a
Ok,

My staff has determined that we will be using custom business objects
for a new app we are creating. we have an object that is called
Employee.

The employee object has about 8 lookup tables with a FK in the
employee table and two other tables that will be custom objects
themselves.

My question is, what is the best way to handle these lookup tables
data in my Employee class? when i create stored procs for getting an
employee should i just use joins and then make public propertys so a
user can change the lookup table fk's and just setup another property
for the lookup table text value? or is there a better way to handle
something like this.

Example:

Employee table
employeeID
stateID
sexID

State table
stateID
State

Sex table
sexID
Sex

i just want to make sure everything is optimized and setup correctly
so we don't run into scalability problems once our app is deployed and
requires structure changes.

any help would be appreciated. thank you.
Jul 21 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
You can use a DataRelation object to accomplish this if they all reside in
the same dataset.
"DKode" <dk***@cfl.rr.com> wrote in message
news:b1**************************@posting.google.c om...
Ok,

My staff has determined that we will be using custom business objects
for a new app we are creating. we have an object that is called
Employee.

The employee object has about 8 lookup tables with a FK in the
employee table and two other tables that will be custom objects
themselves.

My question is, what is the best way to handle these lookup tables
data in my Employee class? when i create stored procs for getting an
employee should i just use joins and then make public propertys so a
user can change the lookup table fk's and just setup another property
for the lookup table text value? or is there a better way to handle
something like this.

Example:

Employee table
employeeID
stateID
sexID

State table
stateID
State

Sex table
sexID
Sex

i just want to make sure everything is optimized and setup correctly
so we don't run into scalability problems once our app is deployed and
requires structure changes.

any help would be appreciated. thank you.

Jul 21 '05 #2

P: n/a
Well,

We are going to be using a dataset as the transfer method between the
data access tier and the business tier, but what we are trying to
determine is the best way to store the lookup table information in our
business layer as i mentioned.

"William Ryan" <do********@nospam.comcast.net> wrote in message news:<eT**************@tk2msftngp13.phx.gbl>...
You can use a DataRelation object to accomplish this if they all reside in
the same dataset.
"DKode" <dk***@cfl.rr.com> wrote in message
news:b1**************************@posting.google.c om...
Ok,

My staff has determined that we will be using custom business objects
for a new app we are creating. we have an object that is called
Employee.

The employee object has about 8 lookup tables with a FK in the
employee table and two other tables that will be custom objects
themselves.

My question is, what is the best way to handle these lookup tables
data in my Employee class? when i create stored procs for getting an
employee should i just use joins and then make public propertys so a
user can change the lookup table fk's and just setup another property
for the lookup table text value? or is there a better way to handle
something like this.

Example:

Employee table
employeeID
stateID
sexID

State table
stateID
State

Sex table
sexID
Sex

i just want to make sure everything is optimized and setup correctly
so we don't run into scalability problems once our app is deployed and
requires structure changes.

any help would be appreciated. thank you.

Jul 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.