Re: Oracle and PICK

In message <XIAgc.8087$Aq.5905_at_nwrddc03.gnilink.net>, Dan <guntermannxxx_at_verizon.com> writes
>
>"Ross Ferris" <ross_at_stamina.com.au> wrote in message
>news:26f6cd63.0404180416.44296c62_at_posting.google.com...
>> "Dan" <guntermannxxx_at_verizon.com> wrote in message
>news:<2Zhgc.5856$Aq.1415_at_nwrddc03.gnilink.net>...
>>
>> Hi Dan !
>>
>> I've read the thread, though my conclusions are somewhat different -
>> I'd suggest the topic should perhaps be "Bad database design sucks -
>> with ANY DBMS !"
>>
>I can see where these conclusions are born out of the discussion.
>
>But the thread started with a real-world problem driven by the fact that the
>company had merged with another company. It therefore had to incorporate and
>map a new set of logical identifiers, over history. The problem wasn't
>necessarily the mapping between logical identifiers themselves, but with the
>deletorious effects it would have on each and every application, report,
>etc. that relied on the original internal data model. An RDBMS solution was
>proposed (see first response to the poster) that, IMO, would have overcome
>this problem easily.

Actually, iirc, it was NOT a specifically RDBMS solution. The same could/should have been done in Pick, with equal ease.

I like relational theory :-) (strange as that may seem). It makes my use of Pick even MORE efficient :-) It's just that Pick doesn't constrain what I *can* do, but I *choose* to let relational constrain what I *should* do. The result is a well-designed and very efficient system.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999