Se si disponesse di un DBA responsabile della distribuzione di database in un ambiente live, quale scelta scegliere per dargli? Uno script di creazione del database o un backup che potrebbe essere ripristinato su un database esistente? Che tipo di vantaggi/svantaggi ci sono? (Stiamo usando MSSQL2000 e MSSQL2005)Distribuzione del database: script o backup
Mentre sono d'accordo con il primo suggerimento dispiegamento di Giovanni di utilizzare un backup del database, preferisco l'idea di almeno avere lo script disponibile per la revisione per consentire la verifica di standard di codifica, la valutazione delle prestazioni, ecc
Se Stiamo cercando qualcosa chiavi che è già stato rivisto, quindi il backup/ripristino è un'opzione perfetta per la prima distribuzione, ancora di più se ci sono dati di configurazione che sono stati "messi in scena" in quel database. Questo aiuta ad evitare istruzioni di inserimento lunghe o complesse.
È un dato che rilascerà oltre il primo verrà sottoposto a script. Nel nostro ambiente richiediamo note di rilascio per specificare il server, l'istanza e il percorso degli script. Gli script devono essere forniti in ordine numerico, separati in cartelle dal database di destinazione, con un secondo set di script di rollback. Abbiamo persino bisogno che ogni script abbia un'istruzione USE nella parte superiore, quindi non dobbiamo preoccuparci di creare nuovi oggetti nel database master! ;)
script di creazione del DB è meglio - si può sempre aprire un blocco note e risolverlo.
io non sono sicuro circa l'opzione di backup, ma con uno script di creazione db il DBA può impostare il database come vuole (deve, permessi, ecc) poi basta creare le tabelle ecc con lo script.
Preferisco uno script per le distribuzioni, sono molto meno invadenti. Un ripristino sovrascriverà l'intero database, i dati e tutto, che probabilmente non è una buona idea per l'ambiente di produzione.
Per la prima distribuzione di ; un backup del database ... è così semplice e veloce.
Se il database è già vivo; deve essere una serie di script numerati. Personalmente, contiamo i miei script e apporto solo modifiche al database tramite script. Ciò garantisce che tutti i database siano sincronizzati o che possano essere sincronizzati in modo davvero semplice.
Alcune persone pensano che sia una specie di anale ... ma non avrò mai un problema di distribuzione della produzione.
Preferisco uno script perché è possibile inserirlo in un repository e tracciarlo. Puoi anche eseguirlo su un server remoto abbastanza facilmente.
Utilizzare gli script sotto il controllo di origine - un bel side-vantaggio è che si costruisce una storia ricercabile di ogni oggetto nel database ed è leggibile. I backup sono scatole nere: non sai cosa faranno al tuo db.
Vorrei andare con gli script: la combinazione di leggibilità umana, compatibilità tramite il controllo del codice sorgente e la possibilità di gestire facilmente gli aggiornamenti del tuo motore di database fanno di questo il modo per andare nella nostra organizzazione.
Definitivamente andare con gli script SQL in quanto possono essere controllati dalla versione. Preferibilmente renderli piccoli e disporre di una sorta di batch per eseguirli in un ordine noto (in modo incrementale) in modo che sia facile eseguirli in un database già in produzione.
Un'alternativa agli script SQL consiste nell'utilizzare un framework di migrazione. Si specificano le modifiche al database in piccoli passi nel codice sorgente.Il vantaggio di un framework di migrazione è che un programmatore che non conosce SQL può semplicemente apportare modifiche al database (che tuttavia non elimina la necessità di conoscere alcune basi del database).
Sono piuttosto espliciti su come si crea e si abbatte un database nei passaggi incrementali. Questo rende più facile testare e ricreare bug in diverse versioni di un sistema di database o di un'applicazione.
Alcuni esempi di quadri di migrazione che io conosco sono:
Il backup è pensato per eseguire effettivamente il backup del database. Man mano che il database cresce, la portabilità diminuisce. Quindi un programmatore ha bisogno solo di un sottoinsieme dei dati. Per ragioni di sicurezza, dovrebbero trattare anche i dati dei test invece dei dati reali. È una buona pratica avere in mano un generatore di dati di prova in modo che gli sviluppatori ei tester possano testare la loro implementazione senza danneggiare i dati in produzione.
Mentre utilizzare un backup del database è una soluzione facile per la distribuzione iniziale, potrebbe non essere una buona soluzione se si esegue la distribuzione su server con impostazioni internazionali diverse dal server da cui è stato eseguito il backup. Abbiamo usato questo approccio in passato e abbiamo avuto problemi dopo il fatto con conflitti di collazione per i nostri clienti oltreoceano. Un backup del database mantiene le sue regole di confronto, mentre uno script crea il database nelle regole di confronto predefinite del server (a meno che non lo specifichi). Per questo motivo ci siamo spostati sugli script per la distribuzione iniziale e i successivi aggiornamenti. – Parmenion