Table with a lot of attributes

I'm planing to build some database project.

One of the tables have a lot of attributes.

My question is: What is better, to divide the the class into 2 separate tables or put all of them into one table. below is an example

create table User { id, name, surname,... show_name, show_photos, ...)

or

create table User { id, name, surname,... )
create table UserPrivacy {usr_id,  show开发者_运维百科_name, show_photos, ...)

The performance i suppose is similar due to i can use index.

---

It's best to put all the attributes in the same table.

If you start storing attribute names in a table, you're storing meta data in your database, which breaks first normal form.

Besides, keeping them all in the same table simplifies your queries.

Would you rather have:

SELECT show_photos FROM User WHERE user_id = 1

Or

SELECT up.show_photos FROM User u
LEFT JOIN UserPrivacy up USING(user_id)
WHERE u.user_id = 1

Joins are okay, but keep them for associating separate entities and 1->N relationships.

There is a limit to the number of columns, and only if you think you might hit that limit would you do anything else.

There are legitimate reasons for storing name value pairs in a separate table, but fear of adding columns isn't one of them. For example, creating a name value table might, in some circumstances, make it easier for you to query a list of attributes. However, most database engines, including PDO in PHP include reflection methods whereby you can easily get a list of columns for a table (attributes for an entity).

Also, please note that your id field on User should be user_id, not just id, unless you're using Ruby, which forces just id. 'user_id' is preferred because with just id, your joins look like this:

ON u.id = up.user_id

Which seems odd, and the preferred way is this:

ON u.user_id = up.user_id

or more simply:

USING(user_id)

Don't be afraid to 'add yet another attribute'. It's normal, and it's okay.

---

I'd say the 2 separate tables especially if you are using ORM. In most cases its best to have each table correspond to a particular object and have its field or "attributes" be things that are required to describe that object.

You don't need 'show_photos' to describe a User but you do need it to describe UserPrivacy.

---

You should consider splitting the table if all of the privacy attributes are nullable and will most probably have values of NULL.

This will help you to keep the main table smaller.

If the privacy attributes will mostly be filled, there is no point in splitting the table, as it will require extra JOINs to fetch the data.

---

Since this appears to be a one to one relationship, I would normally keep it all in one table unless:

You would be near the limit of the number of bytes that can be stored in a row - then you should split it out.

Or if you will normally be querying the main table separately and won't need those fields much of the time.

---

If some columns is (not identifiable or dependent on the primary key) or (values from a definite/fixed set is being used repeatedly) of the Table make a Different Table for those columns and maintain a one to one relationship.

---

Why not have a User table and Features table, e.g.:

create table User ( id int primary key, name varchar(255) ... )

create table Features ( user_id int, feature varchar(50), enabled bit, primary key (user_id, feature) )

Then the data in your Features table would look like:

 | user_id | feature     | enabled
 | -------------------------------
 | 291     | show_photos | 1
 | -------------------------------
 | 291     | show_name   | 1
 | -------------------------------
 | 292     | show_photos | 0
 | -------------------------------
 | 293     | show_name   | 0

---

I would suggest something differnet. It seems likely that in the future you will be asked for 'yet another attribute' to manage. Rather than add a column, you could just add a row to an attributes table:

TABLE Attribute
(
    ID
    Name
)
TABLE User
(
    ID
    ...
)
TABLE UserAttributes
(
    UserID FK Users.ID
    Attribute FK Attributes.ID
    Value...
)

Good comments from everyone. I should have been clearer in my response.

We do this quite a bit to handle special-cases where customers ask us to tailor our site for them in some way. We never 'pivot' the NVP's into columns in a query - we're always querying "should I do this here?" by looking for a specific attribute listed for a customer. If it is there, that's a 'true'. So rather than having these be a ton of boolean-columns, most of which would be false or NULL for most customers, AND the tendency for these features to grow in number, this works well for us.