Re: Are there performance advantages in storing bulky field in separate table?

Robert Treat wrote:
>
> You can be sure that discussion of this topic in this forum will soon be
> visited by religious zealots, but the short answer is "nulls are bad, mmkay".
> A slightly longer answer would be that, as a general rule, attributes of your
> relations that only apply to 1% of the rows are better represented as a one

To fulfill your prophecy of zealotry, I've got a number of tables
with columns that are mostly null that I can't think of that nice a
way of refactoring. I'd love ideas to improve the design, though.

One example's an address table. Most addresses have a few fields
that are typically present (building number, city, state, etc).
Others, as described in various government's address standards,
are fields that are typically absent. For example in US addressing
rules, the "Urbanization Name" line:
http://www.usps.com/ncsc/addressstds/addressformats.htm
MRS MARIA SUAREZ Name
URB LAS GLADIOLAS Urbanization name
150 CALLE A House no. and st. name
SAN JUAN PR 00926-3232 City, state, and ZIP+4
Similarly sparse columns in my address tables are,
titles, division/department Names and mailstop codes.
(described here: http://pe.usps.gov/text/pub28/pub28c3_011.htm)

While I realize I could stick in some string (empty string, or
some other magic string like "urbanization name doesn't apply to
this address") into a table, it sure is convenient to put nulls
in those columns.

I'm quite curious what you'd suggest a well-designed address table
would look like without nulls.