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

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.
Received on Fri Oct 10 2003 - 00:24:50 CEST