Sì, se il database Oracle viene creato utilizzando un set di caratteri Unicode, un NVARCHAR in SQL Server dovrebbe essere migrato a un VARCHAR2 in Oracle. In Oracle, il NVARCHAR il tipo di dati esiste per consentire alle applicazioni di archiviare i dati utilizzando un set di caratteri Unicode quando il set di caratteri del database non supporta Unicode.
Una cosa da tenere presente durante la migrazione, tuttavia, è la semantica della lunghezza dei caratteri. In SQL Server, un NVARCHAR(20) alloca spazio per 20 caratteri che richiedono fino a 40 byte in UCS-2. In Oracle, per impostazione predefinita, un VARCHAR2(20) alloca 20 byte di memoria. Nel AL32UTF8 set di caratteri, che è potenzialmente solo spazio sufficiente per 6 caratteri anche se molto probabilmente gestirà molto di più (un singolo carattere in AL32UTF8 richiede tra 1 e 3 byte. Probabilmente vuoi dichiarare i tuoi tipi Oracle come VARCHAR2(20 CHAR) che indica che si desidera allocare spazio per 20 caratteri indipendentemente dal numero di byte necessari. Questo tende a essere molto più facile da comunicare che cercare di spiegare perché alcune stringhe di 20 caratteri sono consentite mentre altre stringhe di 10 caratteri vengono rifiutate.
Puoi modificare la semantica della lunghezza predefinita a livello di sessione in modo che tutte le tabelle che crei senza specificare alcuna semantica della lunghezza utilizzino la semantica dei caratteri anziché dei byte
ALTER SESSION SET nls_length_semantics=CHAR;
Ciò ti consente di evitare di digitare CHAR ogni volta che definisci una nuova colonna. È anche possibile impostarlo a livello di sistema, ma farlo è sconsigliato dal team NLS:a quanto pare, non tutti gli script forniti da Oracle sono stati testati a fondo rispetto a database in cui NLS_LENGTH_SEMANTICS è stato cambiato. E probabilmente sono stati pochissimi gli script di terze parti.
