Re: Smart Database Tricks

From: Jan Hidders <hidders_at_gmail.com>
Date: Fri, 22 Jun 2007 11:53:53 -0000
Message-ID: <1182513233.710883.177070@c77g2000hse.googlegroups.com>

On 22 jun, 12:44, "David Cressey" <cresse..._at_verizon.net> wrote:

> So, sometimes, we are forced to extend the U of D so as to formalize it,
> prior to mapping the U of D onto database design. Whether we call these
> extensions to the U of D "surrogate keys" or not is moot.

Agreed. Avoid them if you can, but use them if you must. But Vladimir's method seems to dictate (but I could be wrong, he is not explicit on this) that they are always introduced because his method rests upon their presence. In fact, he introduces two of them, one for identifying the entity accross several diferent states, and one for identifying the entity in a certain state. The latter identifier is generated new for each update on the state of the entity (so, if the entity returns to the same state, it still gets a different state identifier). This is great if that is what the organization wants to record in the database, but it it isn't then you are over-modelling.

Also note that he adds these two identifiers to the same entity, whereas it would make more sense to split the entity into two: one for the abstract entity that describes the time-invariant attributes and one for the concrete entity that describes the time-variant attributes that make up its state.

Jan Hiders

Received on Fri Jun 22 2007 - 06:53:53 CDT