MySQL e PostgreSQL come opzioni backend native

La scelta del database fa parte dell’architettura del deployment

In un sistema aziendale, il database non dipende soltanto dalle preferenze di chi sviluppa. L’organizzazione può avere standard operativi, un proprio team di amministratori, procedure di backup esistenti, requisiti del provider cloud o vincoli di un hosting gestito. Per questo Sapphire I.C.D.S. supporta due opzioni backend native, MySQL e PostgreSQL, senza obbligare ogni installazione a utilizzare un unico sistema scelto in anticipo.

Il Roadmap pubblico registra il supporto di PostgreSQL come miglioramento rilasciato insieme alla scelta completa tra i due sistemi. A livello architetturale significa più della presenza di un secondo driver: query, schemi dei moduli e regole di esecuzione devono esistere per entrambi i dialetti e mantenere un comportamento comparabile.

Un contratto comune sopra due driver

I livelli superiori di Sapphire I.C.D.S. non devono dipendere direttamente dalla libreria client di uno specifico database. Il controller dei dati legge dalla configurazione il tipo di backend scelto e ottiene il relativo driver nativo. Per il modulo chiamante resta un insieme comune di operazioni: selezionare righe, modificare dati, ottenere un valore scalare, inserire lotti, gestire transazioni e operare sullo schema.

Questa separazione mantiene la scelta tecnologica nel livello infrastrutturale. Un modulo per articoli o localizzazione formula una richiesta di dominio e lavora con un risultato strutturato, senza decidere come collegarsi a MySQL o PostgreSQL. Le differenze tra i sistemi non sono nascoste da un’astrazione fittizia: vengono gestite dal driver e dal dialetto SQL appropriati.

Modelli SQL separati invece di stringhe condizionali

Sapphire I.C.D.S. mantiene le query ordinarie separate dal modulo aziendale e le divide per dialetto. Una stessa operazione può avere modelli MySQL e PostgreSQL con la medesima finalità e la stessa forma attesa del risultato. Prima dell’esecuzione, il driver attivo seleziona la variante adatta, applica il livello nativo dei parametri e restituisce i dati in un contenitore tabellare comune.

Questa portabilità è più onesta del tentativo di dichiarare universale tutto l’SQL. MySQL e PostgreSQL differiscono per sintassi, tipi, gestione degli identificatori, restituzione dei valori creati e dettagli di alcune espressioni. Modelli separati e verificabili permettono di gestire esplicitamente tali differenze senza riempire il modulo aziendale di ramificazioni.

Che cosa rimane uguale per i moduli

• L’operazione di dominio. Richiedere un elenco, salvare un record o effettuare una modifica transazionale mantiene una finalità aziendale unica.
• I dati in ingresso. Il modulo trasmette parametri strutturati attraverso l’ambiente comune.
• La forma del risultato. Il consumatore riceve una tabella o un valore con campi concordati.
• Il confine transazionale. Le operazioni che devono completarsi interamente usano il contratto comune delle transazioni.
• La selezione del backend. È svolta dalla configurazione e dal controller, non da condizioni sparse nei moduli.

Che cosa la scelta del backend non rende automatico

La presenza di due opzioni native non significa che un database di produzione attivo possa essere sostituito con una sola impostazione. La migrazione richiede trasferimento di schemi e dati, verifica di sequenze e identificatori, confronto dei tipi e controllo di codifiche, indici e comportamento transazionale. Servono un backup, un piano di arresto o sincronizzazione, una prova e criteri di ripristino.

La piattaforma non dichiara nemmeno replica automatica tra MySQL e PostgreSQL, failover integrato tra sistemi o un unico cluster composto da database differenti. Sono compiti infrastrutturali da progettare separatamente. La scelta nativa significa che Sapphire I.C.D.S. funziona con ciascuna opzione in un deployment supportato, non che i due sistemi siano intercambiabili in qualsiasi momento senza preparazione.

Come scegliere tra MySQL e PostgreSQL

Una decisione razionale parte dall’ambiente del cliente. Se l’organizzazione utilizza già MySQL, dispone di backup standardizzati e di un team competente, passare a un altro sistema soltanto per un nuovo progetto può non offrire vantaggi. Analogamente, PostgreSQL è naturale dove rappresenta lo standard aziendale, è disponibile in un’infrastruttura gestita e si integra con monitoraggio e ripristino esistenti.

Non va confrontata solo la prestazione di una query, ma l’intero ciclo di vita: disponibilità di specialisti, aggiornamenti, costo del servizio, osservabilità, politica delle estensioni, procedure di ripristino e requisiti dei dati. Le query particolari di un modulo devono essere misurate su volumi rappresentativi. Il contratto comune non annulla le differenze tra ottimizzatori e indici.

La parità richiede disciplina di sviluppo

Ogni modifica di schema o query deve comparire in entrambi i dialetti se il modulo dichiara il supporto dei due backend. Non basta verificare che i modelli esistano: servono un’installazione pulita, la riapplicazione sicura delle migrazioni, test di lettura e scrittura e confronto dei risultati. Particolare attenzione occorre quando i sistemi contano diversamente le righe modificate o trattano in altro modo un risultato vuoto.

Questa disciplina aumenta l’attività di verifica, ma rende reale la portabilità. Se un nuovo modulo funziona con un solo backend, la limitazione deve essere dichiarata invece di essere nascosta dietro un’affermazione generale. La direzione tecnica ottiene un criterio chiaro: la stessa operazione aziendale deve produrre un risultato equivalente su entrambe le opzioni supportate.

Il risultato operativo

Per l’imprenditore, due backend nativi permettono di inserire Sapphire I.C.D.S. nell’infrastruttura esistente ed evitare cambi di competenze non necessari. Per gli architetti, il livello dati comune impedisce ai moduli di dipendere direttamente da un driver. Per gli sviluppatori, i dialetti SQL separati rendono visibili e verificabili le differenze.

Il valore principale non è proclamare il supporto di due database, ma stabilire un confine di responsabilità. L’organizzazione sceglie e gestisce il backend, il controller collega il driver nativo, il modulo esegue l’operazione di dominio e i test confermano la parità. La scelta tecnologica resta aperta senza nascondere il costo reale di migrazione e manutenzione.