Ferramentas de dados do SQL Server e estrutura de entidades - existe alguma sinergia aqui?

Saindo de um projeto usando o Linq2Sql, suspeito que o próximo (maior) possa me levar aos braços do Entity Framework. Fiz algumas leituras sobre o assunto, mas o que não consegui encontrar é uma história coerente sobre como o SQL Server Data Tools e o Entity Framework devem / podem / devem ser usados ​​juntos.

• Eles foram concebidos totalmente separadamente e usá-los juntos está seguindo o caminho errado?
• Eles são de alguma forma totalmente ortogonais e estou perdendo o objetivo?

Algumas razões pelas quais acho que quero os dois:

• O SSDT é ótimo por ter sql e esquema 'compilados' (verificados) e facilmente versionáveis
• Mas a história de 'migração / atualização' do SSDT não é convincente (para mim): "Atualizar qualquer coisa" funciona bem para o esquema, mas não há como (AFAIK) funcionar com dados.
• Por outro lado, não tentei a migração da EF para saber se ela apresenta problemas semelhantes, mas os bits para cima / para baixo parecem bastante úteis.

Deixe-me colocar em outro ponto de vista. A manutenção do banco de dados do Entity Framework é totalmente inútil em qualquer empresa ou projeto de banco de dados grande.

Os problemas são:

• Atualizações automáticas de esquema. Isso não é absolutamente o que eu quero, pois viola totalmente os fundamentos da manutenção do banco de dados. Os problemas são: (a) alguém executando uma versão mais recente atualiza o banco de dados em vez de obter um problema e (b) as atualizações são agendadas com o dba normalmente fazendo um backup primeiro. Portanto, as atualizações automáticas são inúteis.

• A criação de banco de dados só funciona em casos de borda basicamente degenerados. Nem tente usar recursos avançados de banco de dados - independentemente de qual deles. Exemplo de servidor SQL: campos incluídos em índices, filtros em índices, particionamento, compactação, regras de validação para campos.

• Migração - assume casos de degeneração novamente: sem transformação de dados ou atualização em várias etapas facilmente. Exemplo: A Tabela X possui um campo histórico de "usuário" que registra que o usuário faz alguma coisa. A nova configuração possui uma tabela Usuário, portanto, é necessário criar a tabela do usuário, criar os usuários, criar o campo de referência do usuário na tabela x, atualizá-lo com o usuário da tabela do usuário e excluir o campo do usuário.

A única maneira sensata de lidar com esses cenários são os scripts de geração e migração e o controle de versão adequado.

Agora, o SSDT - que é uma ótima ferramenta para versionar uma versão específica do banco de dados muito melhor do que o Entity Framework, porque na verdade - funciona. Como em: registra todos os recursos. Em nenhum dos bancos de dados que tenho, eu poderia usar o código primeiro - porque sempre temos índices filtrados pelo menos;) A EF nem sequer me levava a 10% do que eu precisava.

Nossa abordagem é:

• Projete o banco de dados no banco de dados e sincronize com um módulo SSDT que é verificado. A sincronização de esquema permite que os desenvolvedores atualizem sua versão rapidamente. Sempre há um banco de dados mestre autoritário com a versão atual em algum lugar (em um servidor especial), portanto, temos uma versão de referência para trabalhar.

• Gere scripts delta conforme necessário para liberações que também são versionadas e possuem um bom mecanismo para implementá-las em um banco de dados.

Há mais de uma maneira de usar o EF com um banco de dados do SQL Server.

1. Code-First ... Você escreve classes e o EF gera as tabelas associadas
2. Banco de dados primeiro ... Você cria as tabelas e o EF gera as classes.

A EF não fará necessariamente todo o trabalho para você. A EF leva você de 80 a 95% lá. Os outros 5 a 20% do seu esforço de desenvolvimento de banco de dados serão complementados com otimizações como Exibições e Procedimentos Armazenados.

Então não, eles não são ortogonais. Mas você terá que decidir qual será sua estratégia geral de design e depois confiar em ferramentas como SSDT para ajudá-lo a otimizar as partes em que a EF produz resultados abaixo do ideal.