If PowerShell is the language for IT professionals in the Windows world, similar to .NET/C# getting the niche for programmers, does this mean that we should get a PowerShell way of working with databases, similar to the LINQ extensions the .NET folks got?
Joel has just posted a very good article on why the notion on PowerShell provider would not work for SQL data access.
So what is the alternative we are getting? Invoking Run-SQLCmd and supplying a SQL query is OK for SQL gurus, but is way to complex for me. After all, there are reasons why people are using AD cmdlets to manage their Active Directory instead of going the ADSI path: reduced complexity, unified PowerShell approach and not having to learn the LDAP query language. All of these apply to SQL, right?
And, by the way, I am not sure I know the answer. Like Richard, I wish SQL 2008 had more cmdlets covering all SQL administration tasks. But then, when looking at what LINQ did to .NET, I can’t help thinking that there might be yet another very elegant solution we are all missing. (Or maybe not, and like in AD, a carefully designed set of cmdlets would do the job.)
PowerShell is all about reducing the complexity and providing unified administrative approach across all platforms. I wonder what needs to be done to get this include the database world.
Tags: PowerShell, SQL
Subscribe by email
Dmitry's Blog: Cloud, PowerShell and beyond 
If you decide, I will follow. the Quest AD Cmdlet coolaid has made me want to drink more. Great Stuff. Thanks, Matthew
Matthew,
Hm… I am not sure I wanted to go as far as that. 😉 I am an AD/Exchange/SharePoint guy. DB stuff has always been the dark side of IT for me. Which I guess is the reason why I kind of hoped that PowerShell would hide the SQL query and SQL command complexity from me, and let me manage SQL databases and work with the data in a transparent and intuitive way. Which did not happen. I hope it will eventually…
Dmitry