(SQL)Optymalizacja zapytania sql, ograniczenie zapytania do obiektów poddanych edycji

0

Mam problem z działaniem zapytania. Zapytanie aktualnie sprawdza i aktualizuje status wszystkich obiektów na 2 warstwach. Zmiany wprowadzane będą na warstwie podbudowa_sieci w kolumnie status. Jak zoptymalizować zapytanie aby sprawdzanie i aktualizacja danych przebiegały tylko w ramach obiektów które zawierają się w rejonie którego status się zmieni?

create trigger test after update on podbudowa_sieci
for each row
begin
	update rejon
	set status =
		(select
		   case statuspol
			   when '1' then 'nierozpoczęte projektowanie'
			   when '2' then 'projektowanie zostało rozpoczęte (koncepcja)' 
			   when '3' then 'ukończone projektowanie' 
			   when '4' then 'akceptacja formalno-prawna rozpoczęcia budowy sieci' 
			   when '5' then 'w trakcie budowy' 
			   when '6' then 'wykonane' 
			   else 'dane archiwalne' 
				end
	   from(
		   select id_0 as idpol, min(case podbudowa_sieci.status
				   when 'nierozpoczęte projektowanie' then '1'
				   when 'projektowanie zostało rozpoczęte (koncepcja)' then '2'
				   when 'ukończone projektowanie' then '3'
				   when 'akceptacja formalno-prawna rozpoczęcia budowy sieci' then '4'
				   when 'w trakcie budowy' then '5'
				   when 'wykonane' then '6'
				   else '7'
			   end) as statuspol
		   from rejon, podbudowa_sieci 
		   where     koncepcja
			   IN ( '1. Przebieg domyślny','3B. Nowy przebieg - zaakceptowany','2C. Przebieg usunięty - odrzucony')
			   and     st_intersects(podbudowa_sieci.geometry,rejon.geom)
		   group by idpol)
	   where id_0 = idpol);
end 

0

Wydajność to nie tylko zapytanie, ale także konstrukcja tabeli. Jakieś indeksy tam w ogóle są? Jak wygląda schemat tych tabel i co one zawierają?
Może sqllite to łyknie, ale w triggerze na tabeli A wykonywanie selecta z tabeli A to dość średni pomysł. Może działa tylko bo jest "after update" :)
Dlaczego nie stworzyłeś jakiegoś słownika statusów? Przecież pisanie zapytań ze statusami o długości kilkudziesięciu znaków to jakaś makabra i niemal pewne błędy w implementacji.

Czy jedyne możliwe złączenie rejonu i podbudowy_sieci to wg danych geograficznych? Nie da się tego wstępnie zawęzić? Tu jest pewnie główny problem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1