Najpierw wyobraź sobie, że te 2 zapytania były tylko tabelami. Zrobiłbyś to:
select a.producer, a.firstquerycolumn, b.secondquerycolumn
from table1 a
join table2 b on b.producer = a.producer
Każdą tabelę można zastąpić zapytaniem (znanym jako widok wbudowany):
select a.Prod, a.AnimalsBought, b.AnimalsExploration
from
( select Producers.name Prod, count(Animals.idanimal) AnimalsBought
from AnimalsBought, Animals, Producers
where (AnimalsBought.idanimal = Animals.idanimal)
and (Animals.owner = Producers.nif)
group by Producers.name
) a
join
( select Producers.name Prod, count(Animals.idanimal) AnimalsExploration
from AnimalsExploration, Animals, Producers
where (AnimalsExploration.idanimal = Animals.idanimal)
and (Animals.owner = Producers.nif)
group by Producers.name
) b
on a.Prod = b.Prod;
Być może trzeba będzie zmienić moje „join” na „full external join”, jeśli jedno zapytanie może zwrócić dane dla producenta, podczas gdy drugie nie. Skłonny byłbym również zmienić strukturę zapytania w następujący sposób, tworząc główne zapytanie na Producentach zewnętrznie połączonych z 2 podzapytaniami (z usuniętymi Producentami):
select Producers.name Prod, a.AnimalsBought, b.AnimalsExploration
from Producers
left outer join ( select Animals.owner, count(AnimalsBought.idanimal) AnimalsBought
from AnimalsBought, Animals
where AnimalsBought.idanimal = Animals.idanimal
group by Animals.owner
) a
on a.owner = Producers.nif
left outer join ( select Animals.owner, count(Animals.idanimal) AnimalsExploration
from AnimalsExploration, Animals
where AnimalsExploration.idanimal = Animals.idanimal
group by Animals.owner
) b
on b.owner = Producers.nif;
(To jest ten typ zapytania, którego wydajność testowałem poniżej).
Zamiast nadużywać tej odpowiedzi informacjami, które prawdopodobnie nie są interesujące dla OP, moje notatki na temat względnej wydajności podzapytań skalarnych i widoków wbudowanych w Oracle (na żądanie PerformanceDBA) są teraz offline tutaj:Uwagi na temat wydajności
