tags:

views:

79

answers:

2
+3  A: 

User, UserInfo, Moderator and Password are redundant tables that offer no benefit.

They only express 1-1 relationships with User, so there is no need to normalize them into seperate tables:

Make one table:

  • UserId
  • Name
  • Email
  • PasswordMd5
  • IsModerator
FlySwat
I need to store the user's password in a hash -form such that nobody connot read it. **Do I need a table for it such that I can check effectively that the password given by the user matches the one in the database?**
Masi
No. You do the hash in your application.
FlySwat
To clarify, you never store the cleartext pass in your database. What good is having both clear and the hash in your DB? Store just the hash, and then apply your hash algo to the inputted password then just compare hashes.
FlySwat
@FlySwat: I know that the app works like, by multiplicating two very large primes, x and y, such that the product, z, is public: x*y=z. z is is the hash in the db and apparently y is in the db too. If user give the right password, the value of x, we let him in. -- **Should I have the parameter password-y in your suggested table too?**
Masi
Please, see my reply to your answer about how I understand your answer: http://stackoverflow.com/questions/1182798/to-improve-a-relation-figure-for-a-database/1182876#1182876
Masi
Never invent your own hashing algorithm. Use SHA1.
FlySwat
@FlySwat: I am speaking of SHA1. I have never used it before. I only know its mathematical background. - **How can I use SHA1 algorithm in my database?**
Masi
Are you sure you're thinking about SHA and not RSA? Your answer above that refers to large primes and public products sounds a lot more like RSA than SHA. They are completely different algorithms with different purposes.
Greg Hewgill
A: 
Masi
This table is improved at the thread http://stackoverflow.com/questions/1182910/how-to-improve-a-erd/1183112#1183112
Masi