The relationship is required in the sens that the data must relate to the data in the other table. You wouldn't want to join a userid and on ProductPartID...

Tables > Users, Properties, UserProperties

Users :

UserID

Name...

Properties

PropertyID

Name

...

UserProperties

UserID

PropertyID

Values

Then you can join those Properties and UserProperties on a specific userid and fetch all the info.

On another note, are you suffixing all your table names with _table???

Select Job_Locale, MAX(Job_Posting_Date) AS Job_Posting_Date, Job_Title from dbo.Job_Posting_Table

where Job_Posting_Status='Open' and Job_Code between 3 and 5 and Job_Area='Chicago'

group by Job_Locale, Job_Title

Just for the record. You can add the userid column to the property table, and then just fetch their info. You can include that logic in a view...

3 replies/minute. Now we're getting back to our normal speed .

You might wanna say where and when the presentation has to take place as we have DBAs from all over the world here.

Why do you have a separate table for each employee exactly??

Good point.... I'm hoping you're not using dynamic sql for this?

oops, right (blabla, 12) .

My argument was more performance-wise, but I'll save you the trouble >> performance shouldn't come in the way of a correct design (which usually performs better anyways).

That's certainly one for the gotcha book, thanx for the info .

I don't think there should be any limit on the in(), but I'd definitly go with the all option leaving that out of the query if possible

Hey Chris, you didn't answer my question yet!!!

That's what I thaught... changing the clustered index and or PK on a live system is a hell of a job .