App / DAL Design

[aeden.jameson]

Hi,

Suppose I'm retreiving all the orders for a customer from the order
DAC. There are several pieces of identifying information I could use
do this. They usually are
1) Primary key, it's usually available. (e.g. Stored in session on
login)

2) Customer identity (e.g. User.Identiy.Name)

What are peoples opinions on this issue?

Below are some of the pro's and con's I could think of. More definitely
needs to be said

Pro's & Con's for 1:

Pros
* Typically sql query has fewer joins than option 2

Cons
* Reliance on session being explicity set w/ primary key. This seems
like it's duplicating
what is provided by option 2
* Reliance on session if it's a high traffic site.

Pro's & Con's for 2:

Pros
* No longer coupled to the login setup, .

Cons
* Query w/ more joins than option 1

Cheers,
Aeden

[sloan]

see my blog:

spaces.msn.com/sholliday/

may and june 2006 entries.

Also.

You should probably write your own IIDentity, and place your unique
identifier there.

I use a UserUUID (guid) to track mine. I think the .Name override of the
IIDentity is where I put it.


<ae***********@gmail.com> wrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

Hi,

Suppose I'm retreiving all the orders for a customer from the order
DAC. There are several pieces of identifying information I could use
do this. They usually are
1) Primary key, it's usually available. (e.g. Stored in session on
login)

2) Customer identity (e.g. User.Identiy.Name)

What are peoples opinions on this issue?

Below are some of the pro's and con's I could think of. More definitely
needs to be said

Pro's & Con's for 1:

Pros
* Typically sql query has fewer joins than option 2

Cons
* Reliance on session being explicity set w/ primary key. This seems
like it's duplicating
what is provided by option 2
* Reliance on session if it's a high traffic site.

Pro's & Con's for 2:

Pros
* No longer coupled to the login setup, .

Cons
* Query w/ more joins than option 1

Cheers,
Aeden