Re: Abstract identifiers, logical pointers, or foreign keys considered not enough

Seun Osewa wrote:

> Hmmm ...
>
> As I see it, problem can be solved with a view which I think is
> roughly analogous to the "abstract data type" you propose. And I
> disagree that payments_id creates an entity that is not present in the
> business model. If it was so there would be no need to group the
> various sort of payments together in a query (as the challenge
> suggests).

You can group several unrelated things together without giving them an id. Like apples and oranges that we put in a basket, we don't need to give them apple_or_orange_id.

Let's think of CUSTOMER, who have a default payment mechanism on record, where the PAYMENT_MECHANISM can be

      Credit Card, (CardtyTYPE, Number )

OR

      Electronic Withdrawal From Account: (Bank Number, AccountNumber)

You really don't get the business user to care that we create an extra ID for these two entities, they are already identifiable through their data.

if we create a PAYMENT_MECHANISM_ID in current databases is just becuase the DBMS vendor doesn't allow us to say:

    type PaymentMechanism = CreditCard | ElectronicWithdrawalFromAccount

So database developers will create a PAYMENT_MECHANISM table and invent PAYMENT_MECHANISM_ID, and even then it is either impossible or extremely awkward to specify the needed integrity constraint.

But if the end user sees

   PAYMENT_MECHANISM_ID: 1020303030303, where he expects a credit card number or account details, he will say "What ???"

Sometimes, they are forced to swallow such invention and make them part of their business model, just because they have to use our software, but not because a mathematical model of the business actually needs surrogate keys.

Costin Received on Fri Oct 10 2003 - 18:54:41 CEST