Home/ Questions/Q 6105199
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T13:57:06+00:00

Currently my users table has the below fields Username Password Name Surname City Address

  • 0

Currently my users table has the below fields

  • Username
  • Password
  • Name
  • Surname
  • City
  • Address
  • Country
  • Region
  • TelNo
  • MobNo
  • Email
  • MembershipExpiry
  • NoOfMembers
  • DOB
  • Gender
  • Blocked
  • UserAttempts
  • BlockTime
  • Disabled

    • I’m not sure if I should put the address fields in another table. I have heard that I will be breaking 3NF if I don’t although I can’t understand why. Can someone please explain?

    Share

    Leave an answer

    You must login to add an answer.

    Need An Account,

    1 Answer

    1. Editorial Team

      There are several points that are definitely not 3NF; and some questionable ones in addition:

      1. Could there could be multiple addresses per user?
      2. Is an address optional or mandatory?
      3. Does the information in City, Country, Region duplicate that in Address?
      4. Could a user have multiple TelNos?
      5. Is a TelNo optional or mandatory?
      6. Could a user have multiple MobNos?
      7. Is a MobNo optional or mandatory?
      8. Could a user have multiple Emails?
      9. Is an Email optional or mandatory?
      10. Is NoOfMembers calculated from the count of users?
      11. Can there be more than one UserAttempts?
      12. Can there be more than one BlockTime per user?

      If the answer to any of these questions is yes, then it indicates a problem with 3NF in that area. The reason for 3NF is to remove duplication of data; to ensure that updates, insertions and deletions leave the data in consistent form; and to minimise the storage of data – in particular there is no need to store data as “not yet known/unknown/null”.

      In addition to the questions asked here, there is also the question of what constitutes the primary key for your table – I would guess it is something to do with user, but name and the other information you give is unlikely to be unique, so will not suffice as a PK. (If you think name plus surname is unique are you suggesting that you will never have more than one John Smith?)

      EDIT:
      In the light of further information that some fields are optional, I would suggest that you separate out the optional fields into different tables, and establish 1-1 links between the new tables and the user table. This link would be established by creating a foreign key in the new table referring to the primary key of the user table. As you say none of the fields can have multiple values then they are unlikely to give you problems at present. If however any of these change, then not splitting them out will give you problems in upgrading the application and the data to support the application. You still need to address the primary key issue.

      • 0