Domanda

Abbiamo un problema comune nello spostare il nostro database SQL 2005 di sviluppo su server Web condivisi presso società di hosting di siti Web.

Idealmente vorremmo un sistema che trasferisca la struttura del database e i dati come una replica esatta.

Questo sarebbe comunemente ottenuto ripristinando un backup. Tuttavia, poiché sono server SQL condivisi, non è possibile ripristinare i backup: non ci viene concesso l'accesso alla macchina effettiva.

Potremmo generare uno script per creare la struttura del database, ma non potremmo effettuare un trasferimento di dati tramite la voce di menu Attività / Importa dati perché potremmo violare i vincoli di chiave esterna poiché le tabelle vengono importate in un ordine in conflitto con il database schema. Inoltre, gli indici potrebbero non essere replicati se impostati per generare automaticamente.

Quindi ci rimane un'operazione disordinata:

  1. Crea uno script in SQL 2005 che generi il database in formato SQL 2000.
  2. Esegui lo script per creare un database SQL 2000 in SQL 2000.
  3. Crea uno script in SQL 2000 che genera la struttura del database SENZA indici e chiavi esterne.
  4. Esegui questo script sul server di produzione. Ora hai una struttura di database in cui caricare i dati.
  5. Utilizzare SQL 2005 per trasferire i dati sul server di produzione con Attività / Importa dati.
  6. Utilizzare SQL 2000 per generare uno script che crea il database con indici e chiavi.
  7. Copia i comandi che generano solo gli indici e le chiavi esterne. Questi si trovano dopo i comandi di creazione della tabella. Nota: in SQL 2005, gli indici e le chiavi esterne sono generati come uno e non possono essere facilmente separati.
  8. Esegui questo script sul database di produzione.

Voila! Il database viene caricato con tutti i dati e le chiavi / i vincoli in atto. Che sistema disordinato e soggetto a errori.

C'è qualcosa di meglio?

È stato utile?

Soluzione

Scott Gu aveva scritto alcuni post su questo argomento:

SQL Server Database Publishing Toolkit per Web Hosting

Altri suggerimenti

Gli script di generazione vanno bene per la creazione degli oggetti del database, ma non per il trasporto delle informazioni del database. Ad esempio, database specifici del client in cui è richiesto allo sviluppatore di precompilare alcuni dati.

Uno dei problemi che ho riscontrato con questo sono i nuovi tipi MAX in SQL Server 2005+. (nvarchar (max), varchar (max), ecc.) Naturalmente, questo è peggio quando si utilizza effettivamente Sql Server Express, che non consente l'esportazione oltre alla creazione di propri script per creare i dati.

Vorrei raccomandare di passare a una società di hosting che ti consente di avere la possibilità di eseguire il backup dei file FTP e NON richiede di utilizzare i tuoi script. Questo è il punto centrale di SQL Server, giusto? Fornire più strumenti più facili da usare. Se la società di hosting lo toglie, puoi anche spostarti su MySql per la facilità con cui scarica le informazioni.

WebHost4Life è un salvavita in questa categoria. Offrono FTP al server di database per caricare il file di backup o i file MDF e LDF per l'allegato! Ero così arrabbiato quando ho visto GoDaddy avere le restrizioni simili che hai menzionato. Il loro strumento non mi ha detto che era una cattiva importazione e non sono riuscito a capire perché il mio sito stava tornando con 500 errori.

Un'altra nota: non sono sicuro di quale sia considerato più sicuro. Ho abilitato le connessioni esterne in GoDaddy e mi sono connesso con Management Studio, e sono stato in grado di vedere tutti i database su quel server! Non potevo accedervi, ma ora ho queste informazioni. Un doppio scemo è che GoDaddy richiede che il nome utente per il DB sia lo stesso del DB! ora tutto ciò che devi fare è password di spam contro quelle centinaia di DB!

Webhost4life, d'altra parte, ha solo il tuo database specifico mostrato in Management Studio. E ti permettono di scegliere il tuo nome DB e il tuo nome utente, indipendentemente l'uno dall'altro. Aggiungono solo lo stesso ID univoco alla fine dell'utente & amp; nomi db per evitare che entrino in conflitto con gli altri.

Non fare affidamento sul ripristino di backup per la copia / trasferimento di database. Devi usare gli script - fidati di me, migliorerai.

Ho usato gli strumenti di RedGate Compare con l'hosting condiviso e funziona bene.

Gli script di generazione del database sono disordinati, ma hanno anche diversi vantaggi che ... beh, rendono il dolore più tollerabile.

Innanzitutto, se trattate gli script DB come vere e proprie attività di programmazione, potete incapsulare il disordine. Se si genera uno script una volta (utilizzando uno strumento di database), è possibile dividere gli aspetti della struttura della tabella dagli aspetti del vincolo (chiavi, indici, ecc.). Allo stesso modo, puoi esportare i dati una volta, ma suddividerli in " sistema " dati che non vengono modificati frequentemente ma sono necessari per il corretto funzionamento (elementi come tasse o tariffe di spedizione, ecc.), dati "di prova" facilmente identificabili e dati "operativi" che devono essere spostati dalla versione DB Vecchia alla versione DB Nuova ( gli ordini della scorsa settimana).

I primi 3 minuti dopo averlo fatto, le cose sono meravigliose: puoi rigenerare un nuovo database con o senza dati di test in pochi minuti. Sfortunatamente, dopo 3 minuti, i database non sono sincronizzati, almeno in termini di dati, se non altrettanto frequentemente in termini di struttura.

Personalmente mi piace avere la struttura di ogni tabella come un file SQL separato (e i suoi vincoli come un file separato in una directory separata, e i suoi dati di test in un file, i dati di sistema in un altro, ecc.). Da un lato, ciò significa che è necessario toccare diversi file diversi quando si effettua una modifica, ma dall'altro rende molto più semplice vedere la granularità di ciò che è stato modificato: è tutto lì nei registri di controllo della versione. (Probabilmente potrei essere convinto che molti file sia una strategia sbagliata ...)

Tutto ciò si basa sul presupposto che tu abbia una qualche possibilità per eseguire effettivamente uno script complesso che coinvolge molti file e non sei solo vincolato a qualche pannello di controllo basato sul Web, che potrebbe essere quello che stai descrivendo quando dici " ; non ci viene concesso l'accesso alla macchina reale. " Sento che non è possibile eseguire lo sviluppo di software personalizzato e non avere alcuni tipi di accesso alla shell sul server; il business dell'hosting è abbastanza competitivo da poter trovare facilmente un host che supporta gli script abbastanza facilmente.

Verifica se la società di webhsoting fornisce myLittleBackup Questa è definitivamente la soluzione più semplice per "installare" un db dal server di sviluppo al server sql condiviso

Risposta per gli utenti di SQL Server 2008.

Ho avuto lo stesso identico problema di OP ma stavo usando SQL Server 2008 e la mia compagnia di hosting condivisa è GoDaddy. Ecco la soluzione per copiare DB + i dati nel database GoDaddy ...

In Visual Studio 2010, vai su Esplora server (in VS Express, penso che sia chiamato esploratore di database). Fai clic con il pulsante destro del mouse sul database e seleziona Pubblica sul provider ... questo apre la procedura guidata di pubblicazione del database ... passa attraverso la procedura guidata e creerà un file xxx.sql sul tuo computer locale ...

Apri SQL Server Management Studio e connettiti al database GoDaddy (dovresti averlo già creato tramite il pannello di controllo GoDaddy nel loro sito Web) ...

Apri Windows Explorer, trova il file xxx.sql e fai doppio clic su di esso. Lo script dovrebbe aprirsi in SSMS. Esegui lo script " nel database appropriato " ... voilà, fatto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top