Re: formula help please
From: Maxim Demenko <mdemenko_at_gmail.com>
Date: Sun, 06 Jan 2008 12:39:28 +0100
Message-ID: <4780BDF0.3090300@gmail.com>
>> Totti schrieb:
>>> statments, and as i understood from you, the constraints and the
>>> primary and foreign keys are essentials in solving such problems.
>>
>> Essentials in solving such problems ( as it seems for me) from
>> Charles' post is:
>> <quote>
>> Oracle has no automatic understanding of how one table
>> should be joined to another table, even if foreign keys are defined
>> </quote>
>> The only exception of this statement i am aware of (which is
>> meaningless in this context, because you aren't using it - is natural
>> join syntax).
>> That means ( for me ) - if some tables are joined and cartesian
>> product (leading to excessive row generation, cpu consumption and temp
>> usage, what may appear as hang) should be avoided - then join
>> conditions should be defined. Defining proper primary/foreign keys is
>> not essential (but of course, may be helpful) to solve such problems...
>>
>> Best regards
>>
>> Maxim
Date: Sun, 06 Jan 2008 12:39:28 +0100
Message-ID: <4780BDF0.3090300@gmail.com>
DA Morgan schrieb:
> Maxim Demenko wrote:
>> Totti schrieb:
>>> statments, and as i understood from you, the constraints and the
>>> primary and foreign keys are essentials in solving such problems.
>>
>> Essentials in solving such problems ( as it seems for me) from
>> Charles' post is:
>> <quote>
>> Oracle has no automatic understanding of how one table
>> should be joined to another table, even if foreign keys are defined
>> </quote>
>> The only exception of this statement i am aware of (which is
>> meaningless in this context, because you aren't using it - is natural
>> join syntax).
>> That means ( for me ) - if some tables are joined and cartesian
>> product (leading to excessive row generation, cpu consumption and temp
>> usage, what may appear as hang) should be avoided - then join
>> conditions should be defined. Defining proper primary/foreign keys is
>> not essential (but of course, may be helpful) to solve such problems...
>>
>> Best regards
>>
>> Maxim
> > The other exceptions would be if you have defined BITMAP JOINS INDEXES > or DIMENSION objects. > > Consider, for example, the following syntax: > > CREATE BITMAP INDEX bjix_fact_prod > ON facts (product.prod_name) > FROM facts, products > WHERE fact.prod_id = product.prod_id;
Still you have to specify join conditions *explicitly* ( as opposite to natural join, where join conditions are obtained by oracle *implicitly*) or am i missing something obvious?
Best regards
Maxim Received on Sun Jan 06 2008 - 05:39:28 CST