Quanta compatibilità hanno i motori DB a livello SQL?

Question

Diciamo che volevo avere un'applicazione che potesse facilmente cambiare il DB sul back-end.
Sto pensando principalmente a SQL Server come back-end primario, ma con la flessibilità di utilizzare un altro motore DB. Firebird e PostGreSQL sembrano avere (dalla mia breve escursione su Wikipedia) il più in comune con SQL Server (in più sono gratuiti).

Quanto sarebbero simili l'installazione del DB, l'accesso, le query, ecc. per Firebird, PostGreSQL e MS SQL Server?

Answer 1

Ho lavorato su un progetto in cui era assolutamente necessario supportare molti database, inclusi almeno Access, SQL Server e Oracle.

Quindi so che può essere fatto. Principalmente DML (SELECT, UPDATE, INSERT ...) è lo stesso e certamente non abbiamo avuto grossi problemi nel farlo funzionare su tutti i database - solo fastidi occasionali. MySQL era l'eccezione in quel momento in quanto semplicemente non era abbastanza capace.

Abbiamo trovato la maggior parte delle differenze nel DDL, ma con l'architettura giusta (che avevamo), non è stato difficile risolvere questo problema.

L'unica cosa che ci ha causato un problema è stata la generazione di ID univoci: l'autoincremento non è standard. Fortunatamente in un database di circa 40 tabelle c'erano solo pochi posti in cui erano necessari ID univoci (buona progettazione di DB). Alla fine generiamo l'ID univoco nel codice e gestiamo eventuali conflitti (tutto nelle transazioni).

Ha reso le cose più facili perché avevamo evitato di utilizzare l'autoincremento per i campi ID, è più difficile pensare a chiavi univoche, ma meglio a lungo termine.

Answer 2

Sfortunatamente, SQL varia ampiamente tra i provider. È quasi impossibile scrivere tutto tranne l'SQL più banale da eseguire su un numero di RDBMS - e quindi sei nel territorio del minimo comune denominatore. Molto meglio usare un livello di astrazione per gestire almeno la connessione al database (incluso accesso, invio di query) e un ORM per gestire lo stesso SQL o SQL per provider.

Se vuoi vedere come variano: buoni esempi sono gli id ??ad incremento automatico e l'ottenimento dell'ID dell'ultimo record inserito.

Answer 3

Bene, le cose CRUD dovrebbero essere le stesse ovunque, ma se costruisci qualcosa di complesso, probabilmente vorrai usare i trigger e le procedure memorizzate ed è qui che la compatibilità diventa bassa. Scrivere un'applicazione indipendente da DBMS di solito significa spostare la maggior parte della logica aziendale al di fuori del database, quindi avere un'applicazione a 3 livelli è, IMHO, un must in questo caso.

In alternativa, potresti usare una libreria wrapper che funziona come un livello di astrazione, ma devo ancora vederne una in grado di fare correttamente il lavoro su una gamma di DBMS. Naturalmente, ciò dipende anche dal linguaggio di programmazione che usi.

Answer 4

Come sottolineato dalle altre risposte, DBMS varia selvaggiamente una volta che si va oltre le cose di base SELECT / INSERT (e talvolta anche lì).

Dobbiamo anche mantenere la compatibilità con diversi DBMS. A mio avviso, l'approccio migliore è di solito utilizzare una sorta di livello di compatibilità. Abbiamo una libreria di astrazione DB interna, ma ci sono diversi strumenti disponibili.

In particolare, potrebbe essere utile guardare gli ORM popolari (Hibernate, nHibernate ecc.). Di solito offrono l'indipendenza dal DB come una sorta di effetto collaterale. Almeno Hibernate ha anche un linguaggio di query speciale che verrà automaticamente tradotto in SQL per il DBMS in uso.