I find that in a lot of cases it makes sense to have subsidiary 1-1 relationships for auxiliary data. The goal, usually, is to wean the application off of using

I find that in a lot of cases it makes sense to have subsidiary 1-1 relationships for auxiliary data. The goal, usually, is to wean the application off of using that data directly. Especially for hot tables in non-column-store databases it can make a big difference - keeping all the data in a table at a similar level of importance and access frequency helps the application cache, DB memory, and disk cache stay relevant. It may or may not be worth going the final step and deleting those tables, but keeping the number of non-null columns in a table small is a big help. For Postgres, at least, null columns have a pretty negligible impact, so even very sparse tables are fine, as long as the data is null-or-useful. That is a recent change in my understanding - you no longer need high density for high performance. The worst case is storing large volumes of non-null not-very-useful data directly in high frequency use tables. Examples I've seen are things like base64 encoded columns holding profile images in the main `user` table.