Database Reference
In-Depth Information
ancies, thus creating a simple easy-to-query structure. In this model, we would
embed
Address
into
Customer
:
Similar volatility
. If the entity you are considering embedding within another en-
tity experiences updates, inserts, and deletes at a similar rate to the entity it will
be embedded into, there is a stronger reason to combine them. The opposite is
the argument for referencing. That is, if you are considering embedding
Cus-
tomer Contact
into
Customer
and
Customer Contact
information experien-
ces almost hourly changes while
Customer
is relatively stable, there is a great-
er tendency towards referencing
Customer
from
Customer Contact
instead
of embedding. This volatility factor also includes considering chronology re-
quirements. That is, if there is a requirement to store all history (e.g. auditing)
on one entity but a current view only on the other entity, you may lean towards
referencing over embedding.
1.
If the entity you are considering embedding is not a key entity
. If
Claim
and
Member
have a relationship but
Claim
has many other relationships, it may
be prudent to reference
Member
from
Claim
instead of embedding the key en-
tity
Claim
into
Member
. It is more efficient and less error prone to reference
the entity that is needed by many other entities. Another example are many-
to-many relationships where the associative entity (the entity that resolves the
many-to-many), is referenced by at least two other entities. In these situations
it may be better to reference rather than embed. For example, I would not con-
sider embedding entity
B
into any of the other entities on this model (I might
consider embedding one or a few of the surrounding entities into
B
, however):
1.
