Qual técnica do PowerShell devo usar para conversar com o SQL Server?

Eu gostaria de usar o PowerShell para substituir os scripts antigos do KornShell que usamos para monitores de instância SQL. No entanto, estou tendo dificuldades para entender todas as maneiras diferentes pelas quais o PowerShell pode realmente conversar com o SQL Server. Não tenho certeza se isso é tudo, mas aqui estão cinco maneiras totalmente diferentes de consultar a versão de um servidor SQL:

1. Classe SQLConnection .NET

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server=MyServer;Database=Master;Integrated Security=True"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = "Select @@version as SQLServerVersion"
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$DataSet.Tables[0]

2. Provedor WMI

$sqlProperties = Get-WmiObject 
    -computerName "MyServer"
    -namespace root\Microsoft\SqlServer\ComputerManagement10
    -class SqlServiceAdvancedProperty
    -filter "ServiceName = 'MSSQLSERVER'"
$sqlProperties.VERSION

3. SMO

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | Out-Null
$smo-var = New-Object ('Microsoft.SqlServer.Management.Smo.Server') 'MyServer\instancename'
$smo-var.VersionString

4. PSDrive

Set-Location SQLSERVER:\SQL\MyServerName\
$server = Get-Item Default
$server.get_VersionString()

5. Invoke-SQLCMD

Invoke-Sqlcmd -Query "SELECT @@version" -ServerInstance "MyServer"

Como devo decidir qual dessas técnicas usar para diferentes cenários? Existem prós / contras de cada um? Algumas dessas técnicas do PowerShell 1.0 foram superadas no 2.0? Alguns deles não funcionarão para se comunicar com servidores SQL 2000 ou 2005?

Em um nível, tenho certeza de que a resposta é "use o que funciona", mas para alguém novo no Powershell, é muito confuso ver tantos exemplos escritos como o nº 1 acima, quando esse é o mais longo e (na minha opinião) menos Exemplo de "PowerShell-like".

Um pouco mais de informação, caso seja relevante: o servidor SQL que realmente executará os scripts do monitor é o SQL 2005, mas é usado para conectar-se a várias instâncias do SQL 2000 até 2008R2.

Obviamente, muito disso se resume a simples escolha pessoal. Aqui estão minhas próprias racionalizações pessoais.

Uso o Powershell com SQL SQL desde o PSH v 1.0 e antes do SQL Server começar a integrá-lo oficialmente. (Quando comecei no PSH, estava administrando servidores SQL Server 2000 e 2005.) Então, aprendi com o SMO (ou é uma encarnação um pouco mais antiga, cujo nome me escapa no momento) e com o .Net e estou acostumado a eles. Geralmente, eu me inclino para o SMO, já que isso facilita muito algumas coisas, como criar scripts para objetos. Meu próprio código usa SMO algumas vezes e .Net algumas vezes. Acho mais fácil usar o .Net para obter conjuntos de resultados simples, por exemplo.

Eu acho que Invoke-SQLCMD faz mais sentido se você tiver muitos scripts TSQL existentes. Se você estiver criando strings e executando-as por meio de -Query, será uma bagunça. Se você tem uma boa noção de como o Powershell trabalha com .Net e SMO, é fácil usar Invoke-SQLCMD ocasionalmente, quando você tem um arquivo de script para executar.

Sempre achei a coisa do PSDrive desajeitada e senti que eles a implementaram porque foram pegos pela ideia de "tudo pode parecer um sistema de arquivos". Eu sei que os caras do * nix amam \ proc e tal, mas sinto que essa implementação parece meio forçada. Eu acho que o PSDrive está bom, talvez até bom se você odeia a interface do usuário, por explorar as coisas, mas nunca escrevi um script que a use.

Eu nunca vi alguém usar o provedor WMI. Então, essa seria minha última escolha.

Então, eu lideraria com o SMO e voltaria ao .Net quando for mais prático.

4 para novos trabalhos, 5 para reutilizar scripts existentes ou locais em que o T-SQL faz mais sentido do que o código de estilo posh / baseado em objeto. Gosto mais desses porque são claros e simples.

Eu tendem a usar SQLPS, se puder. É mais simples e, se eu o usar em scripts, é muito mais fácil ler e digitar menos do que tentar usar o SMO. O SMO tem seu lugar, pois possui um bom poder, mas pode ser confuso às vezes, se você não estiver familiarizado.

Eu acho que quando as versões do SQL Server forem lançadas, o SQLPS será aprimorado. Especialmente porque, com o SQL Server 2012, o SQLPS não é modular, em vez de ser um snapin. Isso permitirá que a Microsoft envie correções ou melhorias com o SQLPS por meio de service packs ou hotfixes, talvez até CUs.

Existem também as ofertas da comunidade, como o SQLPSX , que já possui muito desse código SMO preparado para você como cmdlets e funções. O que eu pretendo não reinventar a roda :)