Quanto è necessario o conveniente scrivere SQL portatile?

Question

Di volta in volta, ho visto persone qui e ovunque che sostenevano l'evitamento di estensioni non portabili al linguaggio SQL, questo è l'ultimo esempio. Ricordo solo un articolo che affermava quello che sto per dire e non ho più quel link.

Hai effettivamente tratto vantaggio dalla scrittura di SQL portatile e dall'eliminazione della sintassi / degli strumenti proprietari del tuo dialetto?

Non ho mai visto un caso che qualcuno si preoccupasse di creare un'applicazione complessa su mysql e poi di dire Sai cosa sarebbe solo peachy? Passiamo a (PostGreSQL | Oracle | SQL Server)!

Le librerie comuni in -say- PHP astraggono le complessità di SQL, ma a quale costo? Ti ritrovi incapace di usare costrutti e funzioni efficienti, per un presunto barlume di portabilità che molto probabilmente non userai mai. Questo mi sembra il libro di testo YAGNI.

MODIFICA: Forse l'esempio che ho citato è troppo snarky, ma penso che il punto rimanga: se stai pianificando un passaggio da un DBMS a un altro, probabilmente stai ridisegnando l'app comunque, oppure tu non lo farebbe 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 dei prodotti di un solo fornitore di database. Perderti i maggiori clienti è commercialmente difficile.

Quando lavori all'interno di un'azienda, potresti essere in grado di beneficiare della conoscenza della piattaforma.

In generale, il livello DB dovrebbe essere ben incapsulato, quindi anche se è stato necessario eseguire il porting su un nuovo database, la modifica non dovrebbe essere pervasiva. Penso che sia ragionevole adottare un approccio YAGNI al porting a meno che non si abbia una richiesta specifica per il supporto immediato multi-vendor. Fallo funzionare con il tuo attuale database di destinazione, ma struttura attentamente il codice per consentire la portabilità futura.

Answer 2

Il problema con le estensioni è che è necessario aggiornarle quando si aggiorna il sistema di database stesso. Gli sviluppatori pensano spesso 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 poiché gli amministratori sono abbastanza intelligenti da non riparare cose che non si rompono, quindi spesso non aggiornano i loro sistemi con ogni nuova versione. Tuttavia, è un vero problema quando aggiorni il tuo database a una versione più recente ma le estensioni non sono compatibili con quella e quindi non funzioneranno. Rende l'aggiornamento molto più complesso e richiede la riscrittura di più codice.
Quando si sceglie un sistema di database, spesso si è bloccati per anni con questa decisione.
Quando si sceglie un database e alcune estensioni, sei bloccato con quella decisione per molto, molto più a lungo!

Answer 3

L'unico caso in cui posso vederlo necessario è quando stai creando 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 un codice specifico del fornitore significa assicurarsi di disporre di un database con prestazioni porrly poiché il codice specifico del fornitore viene solitamente scritto per migliorare le prestazioni di determinate attività su SQL standard ANSII e scritto per favorire l'architettura specifica di quel database. Ho lavorato con basi di dati per oltre 30 anni e non ho mai visto un'azienda cambiare il proprio database di backend senza una completa riscrittura dell'applicazione. Evitare il codice specifico del fornitore in questo caso significa che si sta danneggiando le prestazioni senza alcun motivo per la maggior parte del tempo.

Nel corso degli anni ho anche usato molti prodotti commerciali diversi con backend di database. Senza eccezioni, ognuno di essi è stato scritto per supportare più backend e, senza eccezione, ognuno di essi era un miserabile, lento cane di un programma da utilizzare effettivamente su base giornaliera.

Answer 4

Nella stragrande maggioranza delle applicazioni scommetterei che c'è poco o nessun beneficio e persino un effetto negativo nel provare a scrivere sql portatili; tuttavia, in alcuni casi esiste un caso d'uso reale. Supponiamo che tu stia creando un'applicazione Web per il monitoraggio del tempo. E ti piacerebbe offrire una soluzione self-hosted.

In questo caso i tuoi client dovranno avere un DB Server. Hai alcune opzioni qui. Potresti forzarli a utilizzare una versione specifica che potrebbe limitare la tua base di clienti. Se puoi supportare più DBMS, allora hai un potenziale client più ampio che può usare la tua applicazione web.

Answer 5

• Se sei un'azienda, allora usi la piattaforma che ti viene data
• Se sei un fornitore, devi pianificare più piattaforme

Longevità per le aziende:

• Probabilmente riscrivi il codice client prima di migrare DBMS
• Probabilmente il DBMS sopravviverà al tuo codice client (Java o c # rispetto al mainframe '80)

Ricorda:

L'SQL all'interno di una piattaforma è in genere compatibile con le versioni precedenti, ma non le librerie client. Sei costretto a migrare se il sistema operativo non può supportare una vecchia libreria, un ambiente di sicurezza, un'architettura di driver, una libreria a 16 bit ecc.

Quindi, supponiamo che tu abbia un'app su SQL Server 6.5. Funziona ancora con alcune modifiche su SQL Server 2008. Scommetto che non stai usando il codice client sano ...

Answer 6

Ci sono sempre alcuni vantaggi e alcuni costi nell'uso del "minimo comune denominatore" dialetto di una lingua per salvaguardare la portabilità. Penso che i pericoli legati al blocco di un determinato DBMS siano bassi, rispetto ai pericoli simili per la programmazione di lingue, librerie di oggetti e funzioni, scrittori di report e simili.

Ecco cosa consiglierei come modo principale per salvaguardare la portabilità futura. Crea un modello logico dello schema che includa tabelle, colonne, vincoli e domini. Renderlo il più possibile indipendente da DBMS, nel contesto di database SQL. L'unica cosa che dipenderà dal dialetto è il tipo di dati e la dimensione di alcuni domini. Alcuni dialetti meno recenti non hanno il supporto del dominio, ma dovresti comunque creare il tuo modello logico in termini di domini. Il fatto che due colonne siano disegnate dallo stesso dominio e non condividano solo un tipo di dati e dimensioni comuni, è di cruciale importanza nella modellazione logica.

Se non capisci la distinzione tra modellazione logica e modellazione fisica, imparala.

Rendi portatile la maggior parte della struttura dell'indice. Mentre ogni DBMS ha le sue caratteristiche speciali di indice, la relazione tra indici, tabelle e colonne è quasi indipendente dal DBMS.

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

Quando arriva il momento di muoversi, aspettati alcuni ostacoli, ma aspettati di superarli in modo sistematico.

(La parola "tu" in precedenza è a chi può interessare e non in particolare al PO.)