Newsgroup: it.comp.software.database
Titolo: Modo più performante per verificare l'esistenza di una riga

Ciao a tutti,
ho una tabella A con campi Id e Label e una tabella B con campi Id, Tag 
e AId (FK a A). Devo verificare che esista almeno una riga in A per cui 
non è definita alcuna riga in B. L'idea che mi è venuta è quella di 
eseguire un LEFT OUTER JOIN tra le due tabelle (ON A.Id = B.AId), 
selezionare A.Id e B.Id e tra queste contare quelle per cui B.Id è NULL. 
Questa operazione va eseguita abbastanza spesso e su un discreto numero 
di colonne. Stando alle mie (limitate) conoscenze/competenze, non riesco 
a figurarmi un modo più performante. Esiste? Potete darmi qualche 
consiglio a riguardo?
Grazie,
Giulio
-- 

Giulio Petrucci <sis...@nonono.boh> wrote in
news:4d301a5b$0$19264$
4faf...@reader2.news.tin.it
: 

che te ne fai delle colonne?
se devi verificare l'esistenza non ti serve nemmeno il count; dovrebbe 
essere sufficiente qualcosa del tipo:
select top 1 
tab1.id
from tab1 left join tab2 on 
tab1.id
=
tab2.id
where 
tab2.id
 is null
se ottieni un risultato hai verificato la condizione, con una sola colonna 
in uscita e senza funzioni aggregate
cosa hai dimenticato di dire?
:-)
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 :-)
Eh eh eh... :-)
La situazione sta così: per oguna di queste righe devo compiere una data 
operazione. Questo lo faccio dichiarando un cursore sul risultato della 
select. Ora, la mia domanda è: conviene fare la select e aspettare che 
il cursore non faccia nulla :-) oppure verificare prima che ci siano 
righe "interessanti" nella maniera che hai indicato tu e *poi* fare la 
select vera, aprire il cursore, ecc ecc...?
Grazie,
Giulio
-- 

On 14 Gen, 14:43, Giulio Petrucci <sis...@nonono.boh> wrote:
Se puoi fare un confronto sull'id, e se la numerosità di tuple di a
per cui non esiste b non è elevata, e le tue operazioni non
coinvolgono più che qualche centinaio di migliaia di record, puoi
eseguire le operazione su a, WHERE id not IN (SELECT id FROM b).
Se b non è enorme questo va abbastanza bene. B.id dovrebbe essere
indicizzato.
Luca.

 
imo e' meglio verificare se ci sono righe da aggiornare e solo in caso 
affermativo lanciare l'operazione.
io voto per una stored procedure che:
- verifica se c'e' del lavoro da fare con la select di prima
- se c'e' da fare recupera la lista degli id
- esegue l'aggiornamento facendo un ciclo sulla lista ottenuta al punto 
precedente (con cursore o altro; dipende un po' da quante righe hai da 
aggiornare)
ti conviene comunque fare un paio di prove e vedere cosa e' piu' adatto 
alla tua situazione perche' le variabili sono un po' e combinate:
- ogni quanto controlli
- quante righe contengono le tabelle coinvolte
- quanto spesso hai delle righe da aggiornare
- quante righe devi aggiornare ogni volta
- quali indici hai sulle tabelle coinvolte
- quanto e' pesante l'operazione da eseguire per ogni riga
- in che modo esegui le operazioni (stored procedure, applicazione esterna 
che manda una stringa sql al server, ...)


 che manda una stringa sql al server, ...)
la sincronizzazione avviene tramite stored procedure.
Ciao e grazie,
Giulio
-- 

 riga in A per cui non è definita alcuna riga in B.
Se sei interessato soprattutto ad ottimizzare questa prima fase
di verifica, cerca di riscrivere la query usando il costrutto
WHERE EXIST(), perche' in questo modo la scansione della tabella
si interrompe non appena la condizione di test diventa TRUE.
Altre formulazioni della query continuano a leggere fino alla
fine della tabella perche' devono produrre un set di risultati,
mentre se siamo interessati ad una risposta di tipo si/no la
scansione completa e` superflua.
Tuttavia dovrai sempre verificare il tempo totale dell'operazione
(prima fase di verifica + seconda fase di elaborazione dati).
[ho problemi sulla linea dati da quasi due mesi, non so quando
potro` rispondere di nuovo]