I put before a similar question, but this one the situation is different because I have a table where each field will hold only 1 data.
The below is my table structure. Do you think I should create 2 tables to have less columns in 1 table? I was thinking to separate registration related data (password, e-mail, dataofregistration, profileviews, …) to another table. But does it make any difference at all since each field will have only 1 data?
Could you explain why not?
Or rather, could you explain why some packages do split the user table into a user table and a profile table?
I can see the point when you want custom profile fields (user : profile=1:N), but sometimes there is a 1:1 relation between a user and his/her profile. I really don’t see the use of that.
Maybe you can enlighten me
i don’t see the use for one-to-one tables either, except for two situations:
“large” columns that are infrequently retrieved are split off so that the remaining, more heavily used columns are in shorter rows, meaning that more of them fit on a single page of disk, which leads to faster table scans (note:doing a lot of table scans can be an indicator of poorly optimized queries)
“optional” columns, which may or may not have values, are split off into a separate table so that NULLs can be avoided, meaning that if a particular entity did not have values for these columns, there would be no row (note: this can, ultimately, lead to a scenario where every optional column is in a separate table along with the key, a scenario which i find ludicrous, but which some relational theorists swear by)