Re: object algebra

The world rejoiced as "Marshall Spight" <mspight_at_dnai.com> wrote:
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:c27tbf$2mg0$1_at_gazette.almaden.ibm.com...
>>
>> In theory, what's the practical limit for the number of relations in a
>> database?
>
> 99. More than that and you need three digits to model the number
> of tables.

At first blush, that sounds ridiculous. But.

The design of SAP R/3 was actually _massively_ influenced by this effect, with the caveat that the number is actually FF, because any more than that, and you would need more than 2 nybbles to count the tables.

As a result, they created a notion called "cluster tables," which amount to having a "generic" table in which you store "sets" of information. It was a lot like opening up "files" that then get joined together to stick them into the table.

The database that caused this choice shall remain nameless...

To anyone to whom the relational model is considered deserving of even passing vague respect, this kind of "model" should cause them to feel ill.

Those that think otherwise wouldn't be likely to feel particularly comfortable about it, either, as no one can claim any merit of added efficiency. Doing pretty much anything at all with "clusters" was pretty hideously slow.

SAP wasn't stupid about this [great whopping enormous kludge]; they stored things in clusters that you'd normally be unlikely to want to access again any time soon. The calculation of employees' paycheques, for instance. A "cluster record" would be set up for each cheque, and would actually contain all of the source figures, including (this part is interesting) salary rates and deduction rates.

The interesting upside of that redundancy is that it "plays well" if there are retroactive changes in pay rates. If you can detect that anything has changed that would warrant recalculating a cheque, the system can go back and recalc the paycheque. If the only copy of the employee's salary was in the "salary table," you'd be in trouble if it changed retroactively. SOME redundancy is necessary...

But given any kind of choice, I'd want something better...

-- 
select 'cbbrowne' || '_at_' || 'cbbrowne.com';
http://cbbrowne.com/info/sgml.html
Signs of a Klingon Programmer #7: "Klingon function  calls do not have
'parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM."