Salve a tutti,
senza volonta' di essere esaustivo, il codice
...
FROM owor T0, OUSR T1, awo1 T2, OITM T3
WHERE T0.UserSign = T1.UserId
AND T0.DocEntry = T2.DocEntry
AND T2.ItemCode = T3.ItemCode
....
indica una sintassi di definizione delle clausole di JOIN in stile ANSI 89, che e' deprecata tendenzialmente da tutti i produttori di database relazionali, non perche' meno efficiente ma sostanzialmente perche' fonte di errori di logica da parte dei programmatori, che a fronte di effettive impostazioni di filtro WHERE potrebbero non ben comprendere o specificate anche le clausole di JOIN, rischiando ad esempio l'esplosione di prodotti cartesiani invece dell'effettivo prodotto filtrato di JOIN, ed andrebbe riscritto in standard ANSI 92 dove esplicitamente le entita' vengono messe in relazione con clausole di JOIN appunto espliciti, tipicamente
...
FROM owor T0
{INNER|LEFT|RIGTH|OUTER} JOIN OUSR T1 ON T0.UserSign = T1.UserId
{INNER|LEFT|RIGTH|OUTER} JOIN awo1 T2 ON T0.DocEntry = T2.DocEntry
{INNER|LEFT|RIGTH|OUTER} JOIN OITM T3 ON T2.ItemCode = T3.ItemCode
WHERE ....
....
relativamente ai piani di esecuzione, e' sempre bene verificare che il codice da noi scritto produca piani di esecuzione "efficienti", e per fare cio', senza utilizzare prodotti specifici quali ad esempio i prodotti di Idera (
https://www.idera.com/resourcecentral/datasheets/sql-workload-analysis ) o ancora meglio SQL Sentry (
https://www.sentryone.com/plan-explore ), si puo' anche utilizzare SQL Server Management Studio selezionando nel Menu Query almeno l'opzione "Display estimated execution plan", che, ad esempio, a fronte della query
USE [Pubs]
GO
SELECT *
FROM [dbo].[employee] e;
GO
mostra come informazioni, che l'esecuzione della query comporta (ovviamente) un completo "clustered index scan", mentre ad esempio
USE [Pubs]
GO
SELECT e.[emp_id], e.[fname], e.[lname]
FROM [dbo].[employee] e
WHERE e.[emp_id] = 'PMA42628M';
GO
indica un piano di esecuzione molto diverso, dove la query molto piu' ottimizzata sia in termini di limitazione, con identificazione specifica e limitata della proiezione, che con l'impostazione di un filtro molto restrittivo, consente la defizione di un piano che prevede solamente un "index seek" moltro performante...
specificando anche l'impostazione di "include actual execution plan", si ha poi accesso alle indicazioni piu' approfondite e specifiche sull'esecuzione della esecuzione della query... anche qui, in hoovering con il mouse sul "blocco" interessante di piano, si ha accesso a preziose informazioni...
Red Gate pubblica e distribuisce gratuitamente un valido compendio per meglio comprendere i significati piu' o meno nascosti nei piani di esecuzione, e l'ebook SQL Server Execution Plan e' liberamente scaricabile presso
https://www.red-gate.com/simple-talk/books/sql-server-execution-plans-third-edition-by-grant-fritchey/
altro strumento interessante risulta essere il SQL Server Profiler, eseguendo il quale ad esempio potresti verificare che il codice da te scritto (non relativamente alla definizione implicita di JOIN in standard ANSI 89), comporta, per ogni successiva esecuzione, uan alta percentuale di possibilita' di richiesta di ricompilazione della query, con discard degli eventuali piani di esecuzione, in quanto le entita' coinvolte nella query NON sono full qualified, cioe' non viene specificato l'owner, o meglio lo schema di appartenenza delle entita', e questo solitamente viene risolto dal Tokenizer di SQL Server forzando la ricompilazione della query ad ogni esecuzione, in quanto, a priori, il Tokenizer NON e' in grado di verificare quale entita' sia realmente coinvolta nella query nel caso di dicotomia in schemi differenti, cioe' dove ad esempio la base dati comprenda 2 schema diversi che entrambi contengano l'entita' [employee]; il database user [Andrea] vorra' ad esempio accedere all'entita' [employee] dello schema [schema1], mentre il database user [Federico] accedera' all'entita' [employee] dello schema [schema2]; questo ovviamento non e' un buon presupposto per riutilizzare piani di esecuzione nella cache, in quanto cosi' si spreca solo spazio e risorse;
info utili riguardo la ricompilazione dei piani sono disponibili presso
https://www.mssqltips.com/sqlservertip/5308/understanding-sql-server-recompilations/
saluti omnia
--
Andrea