views:

45

answers:

3

should we always combine one-to-one tables?

I have a user id uid, a table containing the basics:

uid, name, address, etc..

and another table that is essentially the same thing, with the foreign key on the previous user table

uid, stats, etc..

should i just combined them? when does it make sense to and when would i not want to?

+3  A: 

It makes sense to keep these tables separate when it will be very common that the fields in the second table will not be filled out, therefore having the second table allows you to save that much memory per row without that information filled.

In your example, if only a few users will have 'stats, etc', then it may be a good idea to keep that information in a separate table. Don't even create a row for those users without that information.

Aaron
thanks, in my case its always gonna be 1-to-1, i create both rows for everybody
Timmy
In that case, for performance (and a little for storage space), definitely go with just one combined table.
Aaron
+6  A: 

Check out this resource on the Five Normal Forms for Relational Databases. In it you will find some guidelines for deciding how to combine information or split it out into tables.

In a nutshell, use this rule of thumb:

  • Each table should represent one type of thing.
  • The primary key should uniquely distinguish that thing from other items in the table.
  • Every column in the table should depend on the primary key value and only the primary key value.
    • If multiple fields in a single table form a logical sub-group (for example parts of an address), then they probably deserve their own table.
JohnFx
thanks, still seems like it can go either way?
Timmy
In theory, but in most cases you probably should avoid 1-1 tables unless you have a good reason to the contrary like vertical partitioning to address locking or performance issues.
JohnFx
+1  A: 

One-to-one relationship is a thing defined by ER model.

This can be mapped into a relational model in several ways, most widely used of them being:

  • Creating one table with attributes of both entities. Useful for strict 1:1 relationships.

  • Creating one table per entity and referencing them in an additional link table with UNIQUE constraints on both link fields. Useful for (0-1):(0-1) relationships and for adding attributes to the relationships themselves.

  • Creating one table per entity and referencing one table from another one using a FOREIGN KEY constraint on a UNIQUE field. Useful for 1:(0-1) relationships.

Performance issues can influence the choice of the relational representation of this relationship as well.

You may want to read this article in my blog:

Quassnoi