I have an application in which I register a user using only their email and password. Then later on, they fill in their profile, which includes their personal information such as numbers, address, the hours they work during the week, etc.
I'm confused now whether to store all that data in the same table or to have the following:
users (for authentication), persons (for the profile), address (for um, addresses), numbers (you get the gist).
I would like to know a DBA's input on this. How would you design this database for a userbase of 500 people, give or take. Are there going to be problems in the long run if I keep all the fields - around 30 right now - in the same table?
It is a good idea to separate site-used data from invoicing data.
When you are displaying a homepage after your user logs in, you usually want to display username and avatar. Also, you use email and other account info to log in. That is probably some stuff you want to keep handy all the time. Move it into one table then.
Addresses (invoice, delivery, etc.) and phone numbers are usually stored separately, as you only need those when placing an order.
Rule of thumb: keep column count under 30, read as few tables as possible. Of course you should design properly (never mix entities, etc.), but this rule is a simple check that you are not creating something awful.