SQL table design advice

I am building a community site where logon will be by email and members will be able to change their name/nick name.

Do you think I should keep member name/nick name in my members table with other properties of member or create another table, write member name/nick name on that table and associate member’s id.

I am in favour of second option because, I think it would be faster to pull members name from it.

Is it开发者_开发问答 right/better way?

Update: reason is for other table is that I need to pull username for different sections. For example forums. Wouldn't it be faster to query a small table for each username for each post in a from topic?

---

I would keep it one table and set a unique constraint on Email in that table.

I can't see a single advantage in adding another table.

---

Why do you think the second option would be faster?

If nickname is a required one-to-one relation to member ID the appropriate place to store them is in the same table. This is still a indexed single-record search so it should be more-or-less as fast as your other option.

In fact, this solution would probably be faster, since you could get the nickname in the same SELECT as you get the other information.

Update to answer the update to the question:

The second table isn't any smaller in terms of the number of rows. The main factors in a SQL search are 1) number of records in the table and 2) number of possible matches from the indexed part of the search.

In this case, the number of records in your smaller table would be exactly the same as the larger table. And the number of possible matching records returned by the index will always be 1 because the member ID is unique.

The number of columns in the table you're searching is generally irrelevant to the time taken to return the data (the number of column you actually list in the SELECT statement can have an effect, but that's the same no matter which table you're searching).

SQL databases are very, very good at finding data. Structure your data correctly and let the database worry about getting it back to. Premature optimization is, as they say, the root of all evil.

---

Go with the first option: keep the name/nick name in the members table. There's no need to introduce an additional table, and the overhead of a join that goes with it, in this case.

---

Yes, associating member's ID to the other properties is the right way to go.

You can simply create an index on name to speed up your queries.