I have to have lots of user data within the database. Now, I have been considering getting two tables, customers that will only have the id, username and password and the other table userData that will have anything else like title, lastname etc.
Is a prefered method?
The easiest design would invest the fields in a single table. From there, though, you will find a lot of reasons you might like to consider splitting that information up into multiple tables. Out of your description, I cant' tell whether you will find any valid reasons to do this.
If starting with one table, you will probably find it beneficial to separate the information for reasons for example:
- Reducing contention (various areas of the application update different information)
- Truly huge column lists (consider the limit for the DB)
- Other?? (how you are likely to keep your application, maybe?)
In a nutshell, I'd attempt to begin slowly and also have a reason to choose the greater complex design should you go down that path.
There's nothing wrong with this design IMHO. You'll have a
users table and link it to some
users_custom table which has more information. You need to be consistant together with your design. Keep in mind that to be able to have any additional user information you'll also have to
JOIN to that particular data.
In my experience this can be a few preference, if you think that this table will grow with time, consider your design, otherwise just ensure that it stays all-in-one table and correctly index posts that you simply deem necessary.
You are able to go further by getting a
UserLog table to construct a historic look at values because they change.
Yes it's :) Theoretically you will find this so known as "normal forms" (3NF BCnF, etc...). With them, means seperating table into more compact ones :)
It may be easier for you to ensure that it stays all-in-one table. Presuming you'll be enforcing unique usernames, all of the fields (password, first_title, and last_title) possess a functional reliance upon username. Therefore, place the all of them within the same table and have a stabilized database.
Even though you can easily separate first_title and last_title to their own table, queries will receive a lot simpler (less JOINs) should you keep all individuals fields in a single table.