The Coronel, Morris, and Rob database text notes that a "derived attribute need not be physically stored within the database; instead, it is derived by using an algorithm." They further state that "design purity would dictate the elimination of a derived attribute."
Many derived attributes are dynamic, meaning that they constantly change.
- For example, age is a dynamic derived attribute because it changes every year, and therefore it should probably never be stored in a database.
- Instead, the static attribute date of birth should be stored and the age should be derived when needed.
However, some derived attributes are static, meaning that their value does not change after they are derived.
- As a consequence, the decision to never store derived attributes in a database becomes less concrete.
- Performance considerations must also factor into the decision.
-
For example, say you rent a textbook from Amazon.
- Amazon derives the rental due date by using the current date to calculate the end of the semester.
- That due date, however, will not change unless you extend it.
- Because every text rental is associated with a due date, system performance may be enhanced by storing that static due date instead of deriving it each time it is needed.
This is not a cut-and-dried decision however.
- If your book is not received with a postmark of the due date or an earlier date, Amazon will automatically extend your textbook rental period by 15 days and charge you for a 15 day extension.
- The extended due date is also a static derived variable.
- However, since the majority of the rented texts will probably be turned in on time, it is not wise to store the extended due date because of the wasted storage; rather it is better to derive it only if necessary.