Ciao sono uno studente senza esperienza nel settore. La mia domanda può sembrare stupida, ma io ei miei amici stavamo discutendo sull'uso del DDL direttamente nel linguaggio di programmazione (qualsiasi linguaggio può essere Java, PHP ecc.), Volevo sapere che è una cattiva pratica usare i comandi DDL (CREATE , ALTER, tabelle DROP) in un linguaggio di programmazione, ovvero se lo schema del database dovrebbe essere modificato nel codice diretto?
Le istruzioni DDL (Data Definition Language) sono usate raramente ovunque. Spesso, vengono utilizzati in script elaborati da un front-end SQL, avviato manualmente.
Tuttavia, la programmazione del front-end SQL richiede che alcuni programmi Java (C, C ++, quali sono) applichino direttamente DDL sul database.
Allo stesso modo, se si dispone di un'applicazione di grandi dimensioni, è spesso necessario fornire una serie di schermate di manutenzione, disponibili per utenti con privilegi elevati, che emettono istruzioni DDL. Ad esempio, alcuni tipi di attività di manutenzione potrebbero richiedere l'eliminazione e la ricreazione di tabelle, la modifica degli indici e l'aggiunta o la rimozione di trigger. Fornendo le funzionalità del tuo programma, puoi ridurre in modo significativo la possibilità di errori limitando le operazioni in natura o nel tempo.
Infine, il test delle applicazioni orientate al database richiede che lo scaffold dei test sia in grado di emettere DDL in molte circostanze.
Nella mia esperienza (ed è possibile che altri abbiano altre esperienze), un'applicazione che modifica direttamente lo schema proprio di solito è un segno di una cattiva progettazione, ed è probabilmente non necessario . Devo ancora lavorare su un'applicazione in cui lo schema stesso necessario per cambiare dinamicamente in fase di runtime.
Se inizi a modificare lo schema in modo dinamico dall'applicazione, tutte le query del codice dovranno tenere il passo con le modifiche dello schema. Le modifiche allo schema dinamico possono anche rendere impossibile la condivisione del database da parte di altre applicazioni se vengono modificati componenti comuni dello schema. Le stored procedure possono anche incorrere in problemi simili se lo schema cambia in modo tale da non funzionare più. Anche il monitoraggio delle modifiche allo schema del database diventa complicato, a meno che non si registri ogni DDL.
Ci potrebbe essere certi casi in cui è meglio, o anche necessario modificare lo schema del database di un'applicazione mentre l'applicazione è in esecuzione, ma mi sembra che questa sia l'eccezione piuttosto che la regola . Una situazione in cui il codice dell'applicazione potrebbe modificare direttamente gli schemi di database è applicazioni che sono in realtà progettate per questo scopo specifico, come Oracle SQL Developer o Microsoft SQL Studio. Tuttavia stanno modificando gli schemi di altre applicazioni, non i loro schemi.
Il problema con la modifica dello schema DB nel codice è che i comandi DDL devono solo eseguire una volta per l'installazione del database - non una volta per istanza del programma. Tuttavia, se si desidera eseguire i comandi DDL dall'applicazione, è possibile utilizzare un framework di migrazione. Ad esempio, in Java Flyway si scrivono le classi di migrazione e il framework Flyway le esegue per voi. Il framework di migrazione assicura che il DDL sia eseguito nell'ordine corretto e che nessuna migrazione venga eseguita due volte sulla stessa installazione di DB.
Generalmente, le modifiche allo schema non sono eseguite da un'applicazione client di database. Se un'applicazione deve creare e rilasciare regolarmente tabelle non temporanee durante il suo normale utilizzo, direi che è un segno che potrebbe esserci un problema con il design. Ad esempio, se un'applicazione utilizza ALTER TABLE per aggiungere colonne per supportare valori aggiuntivi (indirizzo1, indirizzo2, ecc.), Significa che il DB non è stato normalizzato.
Ma ... devi tenere a mente l'ampiezza dello sviluppo del software. L'emissione delle istruzioni DDL non sarebbe solo comune, sarebbero necessarie, per gestire le applicazioni locali che si collegano ai database locali. Quindi un'applicazione che utilizza SQLite potrebbe dover modificare lo schema automaticamente quando l'applicazione si aggiorna per supportare nuove funzionalità.
È una buona pratica trattare il tuo database come una base di codice separata. Tengo il mio DDL e l'intero database sotto il controllo del codice sorgente. Esistono prodotti come RedGate SQL Source Control che ti permettono di "controllare il tuo database" e ho anche sviluppato un prodotto simile. Questo ti permette di fare diffs e fusioni e script di installazione.
DDL è una o poche cose del tempo. Non gestirlo da Java solo perché sembra nuovo. Ci sono effettivamente ORM che supportano questo, ma in tutti i gruppi con cui ho lavorato abbiamo disapprovato la pratica e non l'abbiamo permesso.
Un database può (raramente, ma non inaudito) essere sostituito da un fornitore concorrente. (Iniziato con MySQL, aggiornato a Oracle o SQL Server). Archiviare DDL in un programma Java semplicemente offusca l'intero ciclo di vita della tua app e del tuo database.
La posizione reale per lo schema / i metadati del database è in:
Leggi altre domande sui tag programming-practices database schema