View Single Post
  #10 (permalink)  
Old March 1st, 2012, 06:44 PM
vbboyd vbboyd is offline
Friend of Wrox
Points: 1,905, Level: 17
Points: 1,905, Level: 17 Points: 1,905, Level: 17 Points: 1,905, Level: 17
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: May 2011
Posts: 411
Thanks: 13
Thanked 7 Times in 7 Posts
Default The Reason being is that....

I still do not understand (and agree) why you need the password. The user ID should be unique, and should be enough to determine user specific content.

The reason being is that the Users are stored in the Employee Database as:
User ID EmployeeIDNo./(Password)
Karen Rodriguez 1345894 ----> Which is also the Employee ID# that is on their Employee ID badges

So hence you have a Employee Database that looks something like this:
Employee Table:
USER ID EmployeeIDNo DepartNo. Department(table)
Karen Rodriguez 1348488 PK 1 1 Accounting
Karen Rodriguez 1383383 5 Fk--->PK 5 Marketing
Karen Rodriguez 14773838 12 12 Sales
Karen Rodriguez 17663636 7 7 Payroll
Karen Rodriguez 84894949 9 9 Research


How do you determine which Karen Rodriguez to pull back from the database?
Good question. You have to use the EmployeeID# which is unique and sets apart the different Karen Rodriguez's from one another. The Employee ID# is the primary Key for the Employee table in the database. The Department column shown up above is normalized and is in a different database table with the DepartNo. in the Employee Table being the foreign keyed link to the Departments table. In the departments table you have the primary key being a SQL server seeded # and different attribute for the description such as Accounting, Payroll, Research, etc, etc. It may not be the best way to set up a database, but I didn't do it, the the DBA did. So you live with what you have to deal with. I don't maybe this might make a good real world example to use when you publish your new ASP.NET 4.5 book later on.
Reply With Quote