我应该使用哪种PowerShell技术与SQL Server通讯？

我最终希望使用PowerShell替换用于SQL实例监视器的旧KornShell脚本。但是，我很难过，无法理解PowerShell可以与SQL Server实际进行通信的所有不同方式。不确定是否全部都是这些，但是这里有5种完全不同的方式可以查询SQL Server的版本：

1. 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. 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.调用SQLCMD

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

我应该如何决定在不同情况下使用哪种技术？每个都有优点/缺点吗？这些Powershell 1.0技术中有一些已被2.0取代吗？它们中的一些不能与SQL 2000或2005服务器通信吗？

在一个层面上，我确定答案是“使用一切有用的东西”，但是对于刚接触Powershell的人来说，看到这么多上面上面＃1的例子感到困惑，那是最长的（在我看来） “类似于powershell”的示例。

如果相关，则提供更多信息：实际将运行监视脚本的SQL Server是SQL 2005，但它用于连接从SQL 2000到2008R2的多个实例。

显然，这很多都归结为简单的个人选择。这是我个人的合理化。

从PSH v 1.0开始，在SQL Server开始正式集成它之前，我一直在使用Powershell和SQL SQL。（当我开始使用PSH时，我是在管理SQL Server 2000和2005服务器。）因此，我学习了SMO（或者它是稍老的化身，现在名称逃脱了）和.Net，我习惯了他们。我通常倾向于SMO，因为它使某些事情变得容易得多，例如编写对象脚本。我自己的代码有时使用SMO，有时使用.Net。例如，我认为使用.Net来获取简单的结果集比较方便。

我认为，如果您有很多现有的TSQL脚本，则Invoke-SQLCMD更有意义。如果要创建字符串并通过-Query执行它们，那将会很混乱。如果您对Powershell如何与.Net和SMO一起使用有很好的了解，那么在有脚本文件要运行时，偶尔使用Invoke-SQLCMD会很容易。

我一直觉得PSDrive有点笨拙，并觉得他们实现了它，是因为他们陷入了“一切都看起来像文件系统”的想法。我知道* nix的家伙喜欢\ proc等，但是我觉得这种实现感觉有点强迫。我认为PSDrive可以，但如果您讨厌UI，则可以很好地探索事物，但我从未编写过使用它的脚本。

我从未见过有人使用WMI提供程序。所以，那将是我的最后选择。

因此，我将领导SMO并在更方便时退回.Net。

4用于新工作，5用于重用现有脚本或放置T-SQL比基于对象/位置样式的代码更有意义。我最喜欢它们，因为它们清晰而简单。

如果可以的话，我倾向于使用SQLPS。它更简单，并且如果我在脚本中使用它，则比尝试使用SMO更加容易阅读且键入更少。SMO之所以具有它的位置，是因为它具有强大的功能，但是如果您不熟悉它，有时会感到困惑。

我认为随着SQL Server版本的发布，SQLPS将得到改进。特别是由于使用SQL Server 2012，SQLPS不是模块化的，而是作为管理单元的。这将允许Microsoft通过Service Pack或修补程序（甚至是CU）推出SQLPS的修复程序或改进功能。

然后还有诸如SQLPSX之类的社区产品，它已经为cmdlet和函数准备了很多SMO代码。我就是要不重新发明轮子:)