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

Hi Seun,

Who ever said ad-hoc queries would be performed by end-users? Or are you not implying that?

Regards,

Ruud de Koter

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). I still do not see any real difference between logical
> pointers and the relational way except that using the relational model
> there is much more flexibility in the way I can manipulate the data.
> For example, I can construct queries that make no sense. I can
> perform operations on a thousand "pointers" at once.
>
> Having said that i have not yet come accross anyone who knows SQL and
> is not grounded in procedural programming. I guess the world is a bit
> different from the 1970's afterall. Computers don't come with BASIC
> or command line shells anymore. SQL is no longer really the end
> user's language. I do not see CEOs asking the DBA for user accounts
> so they can use SQL to generate reports. So the advantage of
> SQL/relational being able to perform ad-hoc queries may not
> necessarily need to be as strong as it used to be. And the advantage
> of a newsgroup such as this, I believe, it that if i am wrong the
> flaws in my logic will be pointed out.
>
> Seun Osewa.
>
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bm49va$io39m$1_at_ID-152540.news.uni-berlin.de>...
> > Here's a very basic problem for you, that you won't get by foreign keys:
> > So you have a table Orders where you keep and each Order has to be paid
> > in full in one payment. So a payment identifier has to stay in the
> > Orders table.
> >
> > Now payments can be of different types:
> > Credit Card payments. Those will be identified and tracked by a
> > special number we get from the clearing house, and will have a whole
> > range of other data, typical to credit card.
> >
> > Check payments: this has another idefntifying number and an
> > entirely different record (tuple) type.
> >
> > Paypal payments. Yet another identifier, yet another tuple type,
> > with different information.
> >
> > Cryptographic money. Cryptographic money is a self contained
> > information token that doesn't need a tuple type, they can just stay in
> > line where they pay for something (for example in the ORDERS table).
> >
> > And other, unknown at this time, payments have to be added in the future
> > (for example prepaid coupons or gift cards ), without any impact
> > whatsoever (like table reorganization) on the existing tables.
> >
> > For security and data integrity reasons all the identifiers (primary
> > keys) for different entities have different datatype, because there's
> > different algorithms to check a credit card payment identifier versus a
> > check payment identifier, vs. a paypal.
> >
> > The main requirement is for user to query if the order is paid, when it
> > was paid, etc, and to display the details of the order together with the
> > relevant payment information to the user, to resolve payment disputes, etc.
> >
> > So how do you model this scenario in the ideal relational database
> > without using abstract identifiers ?
> >
> > One solution might be to introduce an artificial (surrogate key)
> > payment_id. I reject this solution, as it introduces an unnecessary
> > entity, not existent in the business model (users know of "The credit
> > card payment identified by 10241024, or the check payment 10000009, or
> > the cryptographic money 0xABCDEFABCDEF.... -- doesn't matter the
> > representation as long as the software verifies their validity). Plus
> > the constraints are difficult to express and they have to be
> > reformulated once we introduce different types of payments.
> >
> > The solution using abstract identifiers is very easy. Let there be the
> > abstract datatype PAYMENT, then the ORDERS table just needs to contain a
> > REF PAYMENT column. New subtypes of payment may be added at any time,
> > each in their own tables, without anything in ORDERS table being
> > touched. When the programmer is concerned with the ORDERS table he
> > doesn't need to worry of the multiple joins involved with a lot of
> > potential different tables to get the details for credit card, checks,
> > etc. He just needs to use a simple operator, like the "->" (or DEREF can
> > be useful if very verbose) to get access to a PAYMENT value.
> >
> > For example he can use orders.payment->toTextDescription() to get a
> > string of character to display to the user.
> >
> > In any case, the mechanism is simple and doesn't pose any logical
> > problem. Contrary to the claim that logical pointers are illogical. On
> > the contrary, under the model proposed say in The Third Manifesto, this
> > very simple problem is difficult to handle.

-- 
--------------------------------------------------------------------------------------
Ruud de Koter                    HP OpenView Software Business Unit
Senior Software Engineer         IT Service Management Operation
Telephone: +31 (20) 514 15 89    Van Diemenstraat 200  
Telefax  : +31 (20) 514 15 90    PO Box 831
Telnet   : 547 - 1589            1000 AV  Amsterdam, the Netherlands
Email    : ruud_dekoter_at_hp.com

internet: http://www.openview.hp.com/products/servicedesk
intranet: http://ovweb.bbn.hp.com/itservicemanager
--------------------------------------------------------------------------------------