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

Hi,

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bm6o4c$j8uu5$1_at_ID-152540.news.uni-berlin.de>...
> 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.

How about fruits_id? :D Seriously! I think it'll always be possible to support one model of doing things by contrasting its correct/optimal use to a missaplication of the conflicting model. Its good to be able to resist the temptation! This is made worse by the fact that people enspousing one technilogy or one approach to things usually are not motivated to learn to do things properly in the conflicting way. For example, how many of us have ever used Pick or IMS? (I haven't either)

> 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,
The end user never sees this. Only the application programmer, and only if he does not skip over the whole problem by defining a neat little view over the 4 tables.

> 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.

The relational model seems to need such an extra table and key in this case and its a mathematical model ;-) But, yes, a mathematical model is only a model and we can have a million of them and the only difference is that some map more closely to reality than others. And then again it depends on which segment of reality you are talking about. To be too "religious" robs the mind of flexibility and creativity. Sometimes with a little work the "stupid" idea opens the door to improvement. History repeats itself.

>
> Costin
Received on Sat Oct 11 2003 - 17:02:50 CEST