Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
A second example — one that used to apply frequently to SQL Server prior to version 7.0 — is when you
have too much information to fit in one row. Remember that the maximum row size for SQL Server is
8060 bytes of non-BLOB data. That’s a lot harder to fill than version 6.5’s 1962 bytes, but you can still
have situations that require you to store a very large number of columns or even fewer very wide
columns. One way to get around this problem was to actually create two different tables and split our
rows between the tables. We could then impose a one-to-one relationship. The combination of the matching
rows in the two tables then meets our larger row size requirement.
Zero or One-to-One
228
SQL Server has no inherent method of enforcing a true one-to-one relationship. You
can say that table A requires a matching record in table B, but when you then add
that table B must have a matching record in table A, you create a paradox — which
table gets the record first? If you need to enforce this kind of relationship in SQL
Server, the best you can do is force all inserts to be done via a stored procedure.
The stored procedure can have the logic to insert into both tables or neither table.
Neither foreign key constraints nor triggers can handle this circular relationship.
SQL Server can handle the instance of zero or one-to-one relationships. This is essentially the same as a
one-to-one, with the difference that one side of the relationship has the option of either having a record
or not.
Going back to our parent company vs. subsidiary example, you might prefer to create a relationship
where the parent company needs to have a matching record for each subsidiary’s records, but the subsidiary
doesn’t need the information from the parent. You could, for example, have subsidiaries that
have very different customers (such as a railroad and a construction company). The parent company
wants to know about all the customers regardless of what business they came from, but your construction
company probably doesn’t care about your railroad customers. In such a case, you would have zero or
one construction customers to one parent company customer record.
Zero or one-to-one relationships can be enforced in SQL Server through:
❑ A combination of a unique or primary key with a foreign key constraint. A foreign key constraint
can enforce that at least one record must exist in the “one” (or parent company in our
example) table, but it can’t ensure that only one exists (there could be more than one). Using a
primary key or unique constraint would ensure that one was indeed the limit.
❑ Triggers. Note that triggers would be required in both tables.
The reason SQL Server can handle a zero or one-to-one, but not a one-to-one relationship
is due to the “which goes first” problem. In a true one-to-one relationship,
you can’t insert into either table because the record in the other table isn’t there
yet — it’s a paradox. However, with a zero or one-to-one, you can insert into the
required table first (the “one”), and the optional table (the zero or one), if desired,
second. This same problem will hold true for the “one-to-one or many” and the “one
to zero, one, or many” relationships also.