Database Reference
In-Depth Information
attributes. You find out that only 100,000 of the records will use attributes
20 through 100. In this case, 99 percent of the records will use only 20 per-
cent of the attributes, and the other 1 percent of the records will have all
the attributes. This might be a good time to split the entity to prevent hav-
ing a table that is mostly empty. It will also speed the retrieval of the
records that do use all the data, because you will have all that information
in a single, smaller table. As we said, this is a rare case, but you may run
into it when creating a model.
Many-to-Many Relationships
The next stop on our journey though the world of data modeling problems
is the big, bad many-to-many relationship. Once you have a handle on how
to physically implement a many-to-many relationship, working with them
isn't very difficult.
What problems are there that you should be aware of when using
many-to-many relationships? Often, the fact that you have implemented a
pure many-to-many relationship is, in and of itself, the problem. When we
say “a pure many-to-many relationship,” we mean one in which the join
table is made up only of the foreign keys that point to the other tables. For
example, look at the many-to-many relationship shown in Figure 8.9.
F
IGURE
8.9
A “pure” many-to-many relationship
In this example, we have two tables—Tickets and Queue—with a
many-to-many relationship between them, implemented here using
TicketQueue as a join table. Not shown are the other attributes of these
three tables. Both Tickets and Queue contain other elements in addition to
their primary keys. In this case, the join table, TicketQueue, exists only to
define the relationship; it does not add any further information about tick-
ets or queues.
At first glance, you might think this relationship is just fine, but let's
take a moment and think about what we are modeling. We are trying to
Search WWH ::
Custom Search