Table Design: Fields with duplicate information

[snowboarder234]

Created a field for website addresses. Coming across individuals who have multiple websites. Do normalization rules dictate that the second (and all subsequent website addresses) each be set up in a new table so as to avoid having a table with blank fields?



Example:
This?



or this?
tblWebsite [first table]
tblSecondWebsite [second table]
tblThirdWebsite [third table]

[JoeM]

If you want to easily be able to search for a particular website address, it is best to store these in a normalized table.
In such a scenario, you would have a table just to store website addresses, and each would have their own record.
So there would only be one "website" field in the table, and Jane would have two records, one for each website.

[snowboarder234]

This is very helpful. But it leads to a further question: I don't foresee a need to search for a website address, only the student -- and then, having found the student, I want to be able to see what (if any, website(s) they have, ie; personal, professional, academic, etc. So my question is, if it's not my goal to search for a website(s), only the student associated with it, is it still necessary to "normalize" by confining all the websites to one table? I appreciate how keeping the websites confined to one table achieves good normalization, which is my goal.

[JoeM]

Normalization is good programming practice, and a sign of a well-designed database. It usually lends itself to be more easily maintained also.

For example, let's say you have an un-normalized structure, where you have three website fields in your main table. And you program Forms/Reports to that.
Now, let's say some point down the road, somebody actually has 4 website addresses. Now, you have to amend your table to include another field, and update your Reports/Forms to account for this additional field too.

However, if you have a normalized structure like we talked about, all you would need to do is add another record to your websites table. No need to mess with the structure of Tables, Forms, or Reports.