Best practice per massimizzare la portabilità in SQL Server 2016

8

Quando si tratta di sviluppare il prototipo di una soluzione, spesso le tecnologie non sono ancora state decise e potrebbero non essere le stesse che verranno utilizzate nel prodotto finito.

In questi scenari tendo a utilizzare Microsoft SQL Server scrivendo le query il più standard possibile per semplificare l'eventuale migrazione a un altro server.

Esiste un modo o qualche pratica nota per imporre l'uso del dialetto SQL su T-SQL standard direttamente in SQL Server o tramite SQL Server Management Studio (SSMS)?

— s.demuro
fonte

3

La portabilità è un bel obiettivo da manuale, ma raramente accade nella pratica. Quando hai la possibilità di scegliere tra sintassi standard ( <>) e non standard ( !=), senza compromessi in termini di prestazioni o manutenibilità, scelgo sempre standard. Ma quando si tratta di altri costi, o non esiste un equivalente standard, seleziono e divento proprietario. Le cose che ti arrendi solo per la possibilità di cambiare completamente piattaforma in un secondo momento non valgono la pena.

— Aaron Bertrand

6

L'unica volta che la portabilità è un obiettivo realistico è quando stai scrivendo un'app che deve integrarsi con più piattaforme contemporaneamente perché i tuoi clienti usano piattaforme diverse. Anche allora, a meno che tu non voglia limitare la funzionalità e le prestazioni siano terribili su tutte le piattaforme, spedirei pacchetti destinati a sfruttare le funzionalità delle singole piattaforme.

— Aaron Bertrand

1

Solo curioso; nella storia di sempre, hai modificato personalmente il sistema di database utilizzato da un'app per un altro di livello equivalente (ad es. Oracle -> SQLS)? Non ho

— Caius Jard

2

L'altra cosa di cui ero curioso; quanto del tuo prototipo sopravvive ragionevolmente per essere un sistema di produzione completo? La maggior parte dei miei prototipi non condivide quasi nessun aspetto con i sistemi completi che sono stati scritti da loro dopo che il prototipo ha dimostrato un concetto e messo a punto alcuni approcci sensati su come dovrebbe apparire una soluzione; stai rendendo i tuoi prototipi troppo perfetti / ti stai aggrappando troppo a lungo?

— Caius Jard,

16

L'utente Aaron Bertrand ha formulato alcuni commenti che si allineano bene con i miei pensieri sulla tua domanda. Questa è una sfida più che una risposta alla tua domanda specifica, ma penso che sia utile considerare in questo contesto.

La portabilità è un bel obiettivo da manuale, ma raramente accade nella pratica.

Se devi cambiare piattaforma ad un certo punto, ci saranno cambiamenti necessari per l'applicazione, il database e probabilmente molte altre cose. Se puoi essere un po '"indipendente dalla piattaforma" senza troppi sforzi, va bene. Ma è davvero una cattiva decisione aziendale usarlo come obiettivo di progettazione.

Ci sono molti posti online in cui le persone discutono i lati negativi o programmano in questo modo, eccone uno che trovo abbastanza interessante:

I livelli di astrazione del database devono morire!

L'errore di portabilità

L'autore usa un argomento che sento sempre: se usi un buon livello di astrazione, sarà facile spostarti da $ this_database a $ other_database lungo la strada.

Sono cazzate. Non è mai facile

In qualsiasi applicazione non banale supportata da database, nessuno pensa a cambiare database come una cosa facile. Pensare che "la conversione sarà indolore" è una fantasia.

I bravi ingegneri cercano di selezionare gli strumenti migliori per il lavoro e quindi fanno tutto il possibile per sfruttare le caratteristiche uniche e più potenti dei loro strumenti. Nel mondo dei database, ciò significa suggerimenti specifici, indicizzazione, tipi di dati e persino decisioni sulla struttura delle tabelle. Se ti limiti davvero al sottoinsieme di funzionalità che è comune a tutti i principali RDBMS, stai facendo un grosso disservizio a te stesso e ai tuoi clienti.

Non è diverso dal dire "Sto facendo per limitarmi a un sottoinsieme di PHP che è lo stesso in Perl e C, perché un giorno potrei voler cambiare lingua e portare" indoloremente "il mio codice".

Questo non succede.

Il costo del cambio di database dopo lo sviluppo e la distribuzione di un'applicazione è piuttosto elevato. Sono possibili modifiche allo schema e all'indice, modifiche alla sintassi, ottimizzazione e ottimizzazione del lavoro da ripetere, suggerimenti per la regolazione o la rimozione e così via. Cambiare mysql_foo () in oracle_foo () è davvero l'ultimo dei tuoi problemi. Toccerai la maggior parte, se non tutte, del tuo SQL - o almeno dovrai verificarlo.

Non mi sembra "indolore".

— Josh Darnell
fonte

11

Non applicare STD SQL.

Decidi innanzitutto quale DBMS utilizzerai in base alle esigenze del tuo progetto e approfittane.

— McNets
fonte

9

Non proprio.

C'è SET FIPS_FLAGGER 'FULL'.

Questo stampa un avvertimento per SQL non standard, ma alcuni avvertimenti lo sono

Non sono sicuro di quale standard specifico venga utilizzato (e sospetto che possa essere SQL 92)
Da un test rapido questo non si lamenta dell'uso +dell'operatore per la concatenazione di stringhe o funzioni proprietarie come ad esempio, GETDATE()quindi non sembra molto completo.

— Martin Smith
fonte

3

"spesso le tecnologie non sono ancora state decise"

Direi che questo NON è assolutamente il caso della mia esperienza. In realtà non credo di aver mai sentito parlare di questo, tranne forse qualcosa di molto piccolo.

Di solito questo viene stabilito e la nuova soluzione dovrebbe utilizzare ciò che è già in uso.

Sono d'accordo con i commentatori sopra in quanto anche se non è stato stabilito, è necessario stabilirlo prima di iniziare a scrivere query e altro codice. Altrimenti ti stai semplicemente lasciando andare per uno sforzo sprecato in una riscrittura subito.

— Marbry Hardin
fonte