Parte 2: altre cinque differenze tra Oracle e SqlServer

Riprendiamo il tema trattato nell’articolo precedente molto apprezzato da voi lettori, riportanto altre cinque differenze tra la programmazione SQL su ambiente Sql Server e su ambiente Oracle.

 

Confronti tra un campo varchar e una stringa contenente spazi

Riprendiamo lo stesso script utilizzato nello scorso articolo per creare delle tabelle di test. Ricordiamo a tal proposito di fare attenzione all’utilizzo di varchar e varchar2.

Su Sql server avremo:

create table TabellaTest (
       campo1 varchar (50) null,
       campo2 decimal(18,2) null );

insert into TabellaTest
values (‘test’, 35.23)

Mentre su Oracle scriveremo:

create table TabellaTest (
       campo1 varchar2 (50) null,
      campo2 decimal(18,2) null );

insert into TabellaTest
values (‘test’, 35.23)

In ambiente Sql Server, cosa succede se valutiamo un campo varchar in un filtro contenuto in una clausola where? Gli eventuali spazi a destra non saranno considerati. Ad esempio la query seguente avrà comunque come output l’unico record presente nella tabella, nonostante la presenza degli spazi dopo il carattere t.

select      *
from      TabellaTest
where    campo1=’test    ‘

Al contrario, su Oracle tali spazi vengono presi in considerazione. Di conseguenza il filtro precedente risulterà falso e quindi la query restituirà zero righe.

L’esempio può sembrare artificioso, in realtà non è raro trovarsi in una situazione del genere quando confrontiamo le colonne con variabili valorizzate precedentemente. Ricordiamo infine che gli spazi a sinistra sono valutati su entrambi gli ambienti, inoltre gli spazi a destra saranno comunque sempre “salvati” nelle operazioni di inserimento.

 

Righe non committate

Nello scorso articolo avevamo visto che by default le operazioni DML su Oracle devono essere seguite da un commit per risultare persistenti su un database (ricordiamo di fare attenzione ai commit impliciti derivanti ad esempio da operazioni DDL).
Su Sql Server, invece, il commit è necessario solo se viene dichiarata esplicitamente l’apertura di una transazione.

Ma cosa succede se proviamo ad interrogare, prima del commit, una tabella modificata in un’altra sessione?
Su Oracle vedremmo la tabella con i valori originali, come se l’operazione non fosse stato ancora eseguita.
Al contrario, su Sql Server la tabella risulta lockata: tutte le query su di essa resteranno “in running” finché la transazione non verrà chiusa tramite un commit o un rollback. Per forzare l’esecuzione di una query su tabelle lockate occorre inserire l’hint WITH (NOLOCK) nella clausola FROM, subito dopo il nome della tabella. In questo caso, a differenza di Oracle, vediamo i dati come se il commit fosse già stato eseguito.

 

Divisione da interi

Creiamo in entrambi gli ambienti una nuova tabella con un campo di tipo int e inseriamo due record con i valori 1 e 2.

create table TestInteri (
campo1 int);

insert into TestInteri
values (1);

insert into TestInteri
values(2);

La query seguente restituirà due risultati differenti:

select   AVG (campo1)
from   TestInteri;

Su Oracle l’output è dato dal numero decimale 1.5, corrispondente alla media dei valori 1 e 2 trattati anch’essi come decimali.
Al contrario, su Sql Server verrà restituito l’intero 1, a meno di convertire esplicitamente (o implicitamente tramite una moltiplicazione per 1.0) la colonna.

Più in generale, tali considerazione valgono anche per la divisione tra numeri interi: a meno di cast, su Sql Server il risultato sarà sempre un intero (non arrotondato), mentre su Oracle otterremo comunque il decimale “esatto”.

 

Concatenazione tra stringhe e interi

In ambiente Oracle se concateniamo una stringa e un intero tramite l’operatore ||, l’intero verrà convertito implicitamente in stringa. Ad esempio l’output di questa query sarà la stringa a1

select  ‘a’ || 1
from   dual

Al contrario, in ambiente Sql Server, l’operatore di concatenazione tra stringhe + tenterà sempre di convertire il campo varchar in intero (nel caso le colonne abbiano questi due tipi alternati). Al netto di rimuovere la tabella Dual, la query precedente restituirà dunque un’errore di conversione.

 

Contatenazione con null

By default, su Sql Server la concatenazione con l’operatore + tra varie stringhe di cui anche una sola è null, ha come risultato null. Viene seguita la logica per cui il risultante della concatenazione tra una stringa determinata e una stringa sconosciuta risulta essere una stringa sconosciuta. Perciò risulta fondamentale trattare questi casi utilizzando ad esempio la funzione coalesce.

Su Oracle la sitazione cambia: il null lavora come elementro neutro della concatenazione, di conseguenza non impatta il valore degli altri campi.

 

Articoli correlati

Leggi il prossimo articolo sull’analisi del piano di esecuzione di una query.