Sql Server Data Tools & Entity Framework: c'è qualche sinergia qui?

Lasciatemi inserire un altro punto di vista. La manutenzione del database di Entity Framework è assolutamente inutile in qualsiasi azienda o progetto di database di grandi dimensioni.

I problemi sono:

• Aggiornamenti automatici dello schema. Questo non è assolutamente ciò che voglio in quanto viola totalmente i fondamenti della manutenzione del database. I problemi sono: (a) qualcuno che esegue una versione più recente aggiorna il database invece di ottenere un problema e (b) gli aggiornamenti sono pianificati con il dba che normalmente effettua un backup PRIMA. Quindi, gli aggiornamenti automatici sono inutili.

• La creazione di Db funziona solo su casi edge degenerati. Non provare nemmeno a utilizzare le funzionalità avanzate del database, a prescindere da quale. Esempio di server Sql: campi inclusi in indici, filtri su indici, partizionamento, compressione, regole di convalida per i campi.

• Migrazione - assume di nuovo casi degenerati: nessuna trasformazione dei dati o aggiornamento multiparto facilmente. Esempio: la tabella X ha un campo "utente" storico che registra che l'utente fa qualcosa. La nuova configurazione ha una tabella utente, quindi è necessario creare la tabella utente, quindi creare gli utenti, quindi creare il campo di riferimento utente nella tabella x, quindi aggiornarlo con l'utente dalla tabella utente, quindi eliminare il campo utente.

L'unico modo sensato per gestire questi scenari sono gli script di generazione e migrazione e il controllo delle versioni appropriato.

Ora, SSDT - questo è un ottimo strumento per la versione di una specifica versione di database molto meglio di Entity Framework perché in realtà - funziona. Come in: registra tutte le funzionalità. Su nessuno dei database che ho, potrei usare il codice in primis - perché abbiamo sempre almeno degli indici filtrati;) EF non mi porterebbe nemmeno al 10% di quello che mi serve.

Il nostro approccio è:

• Crea un database nel database, quindi sincronizza un modulo SSDT che viene archiviato. La sincronizzazione dello schema consente agli sviluppatori di aggiornare rapidamente la loro versione. C'è sempre un database master autorevole con la versione corrente da qualche parte (su un server speciale) quindi abbiamo una versione di riferimento contro cui lavorare.

• Genera script delta come necessario per le versioni che ottengono anche la versione e dispongono di un buon meccanismo per la loro distribuzione in un database.

Esistono più modi per utilizzare EF con un database SQL Server.

1. Primo codice ... Si scrivono classi e EF genera le tabelle associate
2. Primo database ... Si progettano le tabelle e EF genera le classi.

EF non necessariamente farà tutto il lavoro per te. EF ti porterà dall'80 al 95 percento lì. L'altro 5-20 percento dello sforzo di sviluppo del database verrà integrato con ottimizzazioni come visualizzazioni e stored procedure.

Quindi no, non sono ortogonali. Ma dovrai decidere quale sarà la tua strategia di progettazione generale e quindi fare affidamento su strumenti come SSDT per aiutarti a ottimizzare quelle parti in cui EF produce risultati non ottimali.