When we need to use 1-to-1 relationship in database design?

When do we need to use a 1-to-1 relationship in database design? In my opinion, if two tables are in a 1-to-1 relationship, they can be combined into one table. Is this true?

1. Vertical partitioning for large tables to reduce I/O and cache requirements -- separate columns that are queried often vs rarely.

2. Adding a column to a production system when the alter table is "too expensive".

3. Super-type/subtype pattern.

4. Vertical partitioning to benefit from table (join) elimination -- providing optimizer supports it (again to reduce I/O and cache) .

5. Anchor modeling -- similar to 4, but down to 6NF.

On occasion it's useful for table locks. When you add a column to a database, the whole table gets locked until it's fully rewritten. This has little to no impact when your database has 100k rows. But if you've 100M rows, or 1B rows, it's a whole different story...

It's also useful to avoid dead rows that take too much space. If you're using MVCC and some of your columns are regularly overwritten, it occasionally makes sense to place them in a separate table. Arguably, auto-vacuuming eventually kicks in, but for the sake of sparing hard drive work, better vacuum a few int fields in a separate table than a whole bunch of entire rows full of text, varchar(n) and who know what else.

A last reason would be the abuse of select * in ORMs. If you're storing images or blog posts/articles, for instance, it may make sense to store the blob/text field in a separate table. Because every time it gets loaded for a reason or the other, your ORM is going to load the whole row. When you only need the URL of your image or post, the last thing you want is to pull the whole binary/text from the database; and yet your ORM will do just that...