Finora ho sempre codificato usando l'SQL dialettico raw / embedded. Questo mi sembra ovviamente sbagliato perché ti lega a tecnologie concrete, quindi il tuo software non può essere distribuito su nessuna macchina, specialmente sui server.
In generale (indipendentemente dal linguaggio di programmazione e RDBMS), quali opzioni si hanno in questo caso? Quanto sono bravi ognuno di loro? Cosa diresti è l'approccio standard?
Generalmente ciò che dovresti cercare è di astrarre il codice del tuo database nel proprio livello (assembly, dll o qualsiasi altra cosa).
Nel codice dell'applicazione si chiama l'interfaccia che "dietro le quinte" elabora il codice di database necessario e chiama che per eseguire il lavoro. A seconda di come è configurata la tua applicazione, questo potrebbe essere qualcosa deciso al momento della compilazione, dell'installazione o del tempo di esecuzione.
Una tecnologia chiave per cercare è Inversion of Control o Iniezione delle dipendenze . Questo ti permetterà di esercitare questo controllo sulla tua applicazione e decidere quale versione del codice ti serve.
Francamente come una persona del database, l'utilizzo del sapore specifico del codice per il tuo database back-end è il codice più efficiente che puoi scrivere. Nei miei 30 anni di lavoro con i database, non abbiamo mai cambiato il back-end del database per un'applicazione e le uniche situazioni in cui sembra necessario sono quando si inizia con una scelta sbagliata per iniziare (come Access quando è necessario un database di grandi dimensioni) o se vendi software Off-the-Shelf (COTS) commerciale che deve supportare qualsiasi back-end del client. Sacrificare le prestazioni oggi nell'idea che un giorno potrebbe essere necessario cambiare i backend non è un buon modo per andare. C'è molto di più nel cambiare il back-end di un database dopo che ha molti record rispetto alla semplice modifica del codice dell'applicazione e il dba intelligente preferisce non correre il rischio.
(Questa risposta ha a che fare con le istruzioni SQL stesse e non con il modo in cui vengono distribuite.)
Non penso che lo definirei standard, ma l'approccio più comune che ho visto è quello di utilizzare il sottoinsieme "minimo comune denominatore" delle funzionalità SQL supportato da tutte le piattaforme di destinazione. Ad esempio, se una delle piattaforme di destinazione non supporta le espressioni di tabella comuni, non utilizzerai mai espressioni di tabella comuni.
Questo approccio elimina la flessibilità SQL e alcune prestazioni per la flessibilità di implementazione.
Alcune varianti SQL possono essere mascherate dalla sostituzione delle macro al momento della compilazione. Una macro potrebbe espandersi su una funzione DATE_ADD() su una piattaforma e su un valore datetime + un valore intervallo su un'altra. Questo può avvicinarti a prestazioni ottimali su tutte le piattaforme di destinazione per un sottoinsieme leggermente più ampio di funzionalità del linguaggio SQL, ma può essere un vero problema da mantenere.
L'approccio a forza bruta consiste nel mantenere un insieme di differenze specifiche della piattaforma per tutte le istruzioni SQL. Dichiarazioni semplici come SELECT * FROM TABLENAME possono essere condivise su tutte le piattaforme; dichiarazioni più complesse che sfruttano funzionalità o sintassi specifiche della piattaforma hanno versioni diverse per ogni piattaforma. Secondo la mia esperienza, questo approccio richiede un sacco di test automatici per assicurarsi che tutte le piattaforme si comportino allo stesso modo.
Non ci ho pensato molto, ma penso che più la piattaforma-agnostica vuoi essere, più è probabile che tu debba finire vicino all'approccio forza-bruta. Quanto è difficile? Bene, i candidati più probabili sono gli strumenti CASE del database e le utilità dello schema del database, e non ce ne sono molti che mirano a più di una manciata di piattaforme attuali. Suppongo che sia molto difficile.
Altri hanno suggerito di astrarre il livello del database, questo va bene, ma alla fine si avrà un codice di database diverso per piattaforme di database diverse, specialmente se il codice del database utilizza tecnologie di piattaforma database specifiche. Questo può essere gestibile, ma se l'applicazione ha 400 tabelle e 1000 proc memorizzati su Oracle e devi portare quel server SQL, è una grande montagna da scalare.
Un approccio alternativo è scrivere una dichiarazione SQL che verrà eseguita su tutte le piattaforme DB. SQL stesso è standardizzato (sq-89, sql-92, sql3) ecc. Se tutte le piattaforme supportano sql-92, assicurarsi che i dati, le query e gli aggiornamenti utilizzino il codice compatibile sql-92. Quindi il livello dati astratti esegue una serie di query, indipendentemente dalla piattaforma DB.
Se fai questo approccio, dovranno essere fatti dei sacrifici e potresti avere più codice di applicazione per supportare il livello dati. Alcuni database non supportano stored procedure, ecc. Ma lo sql che viene inviato in entrata e in uscita deve essere universalmente accettato, quindi è un DB incrociato.
Ho lavorato su una grande applicazione che ha cambiato database (da SQL Server a MySQL). C'è molto che ho imparato in quel momento. Penso che se vuoi sviluppare un'applicazione per database incrociati devi tenere a mente alcune cose. In primo luogo, avere un elenco di database supportati. Non avrai le risorse per sviluppare e testare tutti i database. In secondo luogo, utilizzare un ORM che supporti tutti i database a cui si mira o (e questo potrebbe essere preferibile) attenersi a SQL di base che funziona su tutti i database di destinazione. Utilizzare solo SQL diverso per ogni database se si verifica un problema di prestazioni. A seconda dell'applicazione, è possibile ottenere molto lontano con le istruzioni "standard" Select, Join, Insert, Update ed Delete.
Leggi altre domande sui tag database cross-platform