Dada a definição existente para o LocalDB do SQL Server 2012 como
O SqlLocalDB é um mecanismo de banco de dados local e de baixa sobrecarga do SQL Server 2012 (e versões futuras) que permite que os desenvolvedores se concentrem no desenvolvimento em vez da configuração ou segurança da instância.
Eu estava curioso para saber como seria o caminho do desenvolvimento no LocalDB para uma instância de produção, especialmente à luz dos problemas com instâncias de usuário (ca. SQL 2005) e tentar promover um deles para produção e os desenvolvedores perderiam a noção de qual instância eles estavam realmente tentando promover. Uma pesquisa rápida no StackOverflow denuncia esses problemas de várias formas. O LocalDB melhora/simplifica a implantação em tais circunstâncias?
...
Não é muita diferença, para ser honesto. Embora
User Instancesnão seja mais um fator, ainda é muito fácil para um desenvolvedor criar várias instâncias SqlLocalDb e perder a noção de qual delas contém a versão "verdadeira" da verdade.O que o LocalDb faz é eliminar a necessidade de configurar uma instância completa baseada em serviço do SQL Server (Express ou não) e reduz a complexidade do modelo de segurança. Ainda cabe ao desenvolvedor ou à equipe implementar boas práticas de desenvolvimento com relação ao controle e promoção do código-fonte. Conforme expresso nos comentários, existem várias maneiras de promover o código de uma instância local para produção (espero que por meio de algum tipo de sistema de controle de qualidade/teste primeiro):
(Deixei de desanexar/anexar intencionalmente porque o backup/restauração é muito mais seguro. Com desanexar, se algo acontecer com o arquivo .mdf durante ou após a desanexação, você terá zero cópias do seu banco de dados. Se um backup der errado, você ainda tem a fonte.)
Se algum deles é mais ou menos propenso aos mesmos tipos de problemas de hoje, depende mais da disciplina da equipe e dos procedimentos estabelecidos do que se eles usam Express ou LocalDb para desenvolvimento local. NA MINHA HUMILDE OPINIÃO.
O bom que o LocalDb fornece sobre as instâncias do usuário é que, se você se conectar a uma única instância do LocalDb, não acabará com o caso específico em que, toda vez que usar
AttachDbFileName, obterá uma nova cópia do banco de dados. A parte mais problemática é que você altera uma tabela em uma instância e, em seguida, obtém um erro de seu aplicativo porque está conectado a uma cópia que não possui alteração na tabela. Como você apontou, isso levou a um fluxo interminável de confusão e perguntas semelhantes no SO. Na verdade, o SqlLocalDb ainda suportaAttachDbFileName, mas acho que será muito pouco usado, se é que alguma vez.Com o LocalDb, é menos provável que você se depare com esses problemas, mas eles ainda existem. É uma ferramenta diferente com algumas vantagens, mas ainda pode ser usada de forma inadequada.