Quanto è necessario o conveniente scrivere SQL portatile?

Question

Più volte, ho visto persone qui e altrove che sostengono l'evitamento di estensioni non proporzionali al linguaggio SQL, this è l'ultimo esempio. Ricordo solo un articolo che afferma ciò che sto per dire e non ho più quel collegamento.

Hai mai tratto vantaggio dalla scrittura di SQL portatile e dal rifiuto degli strumenti/sintassi proprietari del tuo dialetto?

Non ho mai visto un caso in cui qualcuno si prendesse cura di costruire un'applicazione complessa su mysql e poi dicendo: Sai cosa sarebbe solo peachy? Passiamo a (PostGreSQL | Oracle | SQL Server)!

Le librerie comuni in -say- PHP fanno astrazione delle complessità di SQL, ma a quale costo? Finisci per non essere in grado di usare costrutti e funzioni efficienti, per un presunto barlume di portabilità che probabilmente non userai mai. Questo suona come YAGNI da manuale.

EDIT: Forse l'esempio che ho citato è troppo snarky, ma penso che il punto rimane: se si sta progettando una mossa da un DBMS ad un altro, è probabile che ridisegnare l'applicazione in ogni caso, o si potrebbe non essere farlo affatto.

Answer 1

I fornitori di software che si occupano di grandi aziende potrebbero non avere scelta (in effetti è il mio mondo) - i loro clienti potrebbero avere politiche di utilizzo di un solo prodotto di un fornitore di database. Perdere i maggiori clienti è commercialmente difficile.

Quando lavori a all'interno di, puoi trarre vantaggio dalla conoscenza della piattaforma.

In generale, il livello DB dovrebbe essere ben incapsulato, quindi anche se si dovesse eseguire il porting in un nuovo database, la modifica non dovrebbe essere pervasiva. Penso che sia ragionevole adottare un approccio YAGNI al porting, a meno che non si disponga di un requriement specifico per il supporto immediato di più fornitori. Fatelo funzionare con il vostro attuale database di destinazione, ma strutturate il codice attentamente per consentire la portabilità futura.

Answer 2

Nella stragrande maggioranza delle applicazioni che avrei scommesso non c'è poco o nessun vantaggio e nemmeno un effetto negativo di provare a scrivere sql portatile; tuttavia, in alcuni casi esiste un caso d'uso reale. Supponiamo che tu stia costruendo un'applicazione Web per il monitoraggio del tempo. E ti piacerebbe offrire una soluzione self-hosted.

In questo caso i client dovranno disporre di un server DB. Hai alcune opzioni qui. Potresti costringerli a utilizzare una versione specifica che potrebbe limitare la base di clienti. Se è possibile supportare più DBMS, si dispone di un potenziale cliente più ampio che può utilizzare la propria applicazione Web.

Answer 3

• Se sei aziendale, quindi si utilizza la piattaforma si è data
• Se sei un fornitore, è necessario pianificare per più piattaforme

longevità per aziendale:

• Probabilmente si riscriverà il codice client prima di migrare DBMS
• Il DBMS probabilmente sopravviverà al codice client (Java o C# contro '80 mainfra Mi)

Ricorda:

SQL all'interno di una piattaforma di solito è compatibile con le versioni precedenti, ma librerie client non lo sono. Sei obbligato a eseguire la migrazione se il sistema operativo non supporta una vecchia libreria o ambiente di sicurezza o architettura driver o libreria a 16 bit, ecc.

Pertanto, si supponga di avere un'app su SQL Server 6.5. Funziona ancora con alcune modifiche su SQL Server 2008. Scommetto che non stai utilizzando il codice cliente sane ...

Answer 4

Il problema con le estensioni è che è necessario aggiornarle quando si aggiorna il sistema stesso del database . Gli sviluppatori spesso pensano che il loro codice durerà per sempre, ma la maggior parte del codice dovrà essere riscritta entro 5-10 anni. I database tendono a sopravvivere più a lungo della maggior parte delle applicazioni, dal momento che gli amministratori sono abbastanza intelligenti da non aggiustare cose che non sono rotte, quindi spesso non aggiornano i loro sistemi con ogni nuova versione.
Tuttavia, è un vero problema quando si aggiorna il database a una versione più recente, ma le estensioni non sono compatibili con quella e quindi non funzionerà. Rende l'aggiornamento molto più complesso e richiede più codice da riscrivere.
Quando scegli un sistema di database, sei spesso bloccato con quella decisione per anni.
Quando scegli un database e alcune estensioni, sei bloccato con questa decisione per molto, molto più a lungo!

Answer 5

L'unico caso in cui posso vederlo necessario è quando si crea un software che il cliente acquisterà e utilizzerà sui propri sistemi. Di gran lunga la maggior parte della programmazione non rientra in questa categoria. Rifiutare di utilizzare codice specifico del fornitore è quello di assicurarsi di disporre di un database che si comporta in modo porroso poiché il codice specifico del venditore viene solitamente scritto per migliorare le prestazioni di determinate attività su SQL standard ANSII e scritto per sfruttare l'architettura specifica di quel database. Ho lavorato con i database per oltre 30 anni e non ho mai visto un'azienda cambiare il loro database di back-end senza una completa riscrittura delle applicazioni. Evitare il codice specifico del fornitore in questo caso significa che stai danneggiando le tue prestazioni senza motivo per la maggior parte del tempo.

Ho anche utilizzato molti prodotti commerciali diversi con i database back-end nel corso degli anni. Senza eccezioni, ognuno di essi è stato scritto per supportare più backend e, senza eccezioni, ognuno di loro era un cane lento e miserabile da utilizzare quotidianamente.

Answer 6

Ci sono sempre alcuni vantaggi e alcuni costi nell'uso del dialetto "minimo comune denominatore" di una lingua per salvaguardare la portabilità. Penso che i pericoli del lock-in su un particolare DBMS siano bassi, se confrontati con i pericoli simili per la programmazione di languges, librerie di oggetti e funzioni, scrittori di report e simili.

Ecco cosa consiglierei come il principale modo di salvaguardare la portabilità futura. Crea un modello logico dello schema che include tabelle, colonne, vincoli e domini. Rendi questo come DBMS indipendente come puoi, nel contesto dei database SQL.Circa l'unica cosa che dipende dal dialetto è il tipo di dati e le dimensioni per alcuni domini. Alcuni dialetti più vecchi mancano del supporto del dominio, ma dovresti comunque creare il tuo modello logico in termini di domini. Il fatto che due colonne siano tratte dallo stesso dominio e che non condividono solo un tipo di dati e una dimensione comuni è di fondamentale importanza nella modellazione logica.

Se non si capisce la distinzione tra modellazione logica e modellazione fisica, apprenderla.

Rendere il più possibile portatile la struttura dell'indice. Mentre ogni DBMS ha le proprie caratteristiche speciali dell'indice, la relazione tra indici, tabelle e colonne è praticamente indipendente dal DBMS.

In termini di elaborazione SQL CRUD all'interno dell'applicazione, utilizzare costrutti specifici DBMS ogni volta che è necessario, ma provare a mantenerli documentati. Ad esempio, non esito a utilizzare il costrutto Oracle "CONNECT BY" ogni volta che penso che mi farà del bene. Se la tua modellazione logica è stata indipendente dal DBMS, gran parte del tuo CRUD SQL sarà anche indipendente dal DBMS anche senza molto sforzo da parte tua.

Quando arriva il momento di spostarsi, aspettatevi alcuni ostacoli, ma aspettatevi di superarli in modo sistematico.

(La parola "tu" in quanto sopra è quello di chi può interessare, e non per l'OP in particolare.)