anchor.diff:  
   - Supports any database (MSSQL, MySQL, Postgre, Oracle, Odbc, ...)
   - Changing the database is not actually huge work
  -- Makes effective simple SQL 
  +- Makes effective simple SQL
   - Supports async database operations
  -- Use it e.g. for web servers
  -- User's code stays simple
  +- Simplifies user code
   - Open source
   
   Not so good:
  
positive.code: 
  * Because result types are auto-generated, FSharp.Data.SqlClient doesn't support so-called [multi-mapping](http://stackoverflow.com/a/6001902/862313)
  * As FSharp.Data.SqlClient is based on features specific for Sql Server 2012; Dapper provides better range of supported scenarios, including Mono
  * Other side of this is that FSharp.Data.SqlClient fully supports SqlServer-specific types like [hierarchyId](http://technet.microsoft.com/en-us/library/bb677173.aspx) and 
  [spatial types](http://blogs.msdn.com/b/adonet/archive/2013/12/09/microsoft-sqlserver-types-nuget-package-spatial-on-azure.aspx), which Dapper does not
  * FSharp.Data.SqlClient fully supports User-Defined Table Types for input parameters with no additional coding required, 
  [as opposed to Dapper](http://stackoverflow.com/questions/6232978/does-dapper-support-sql-2008-table-valued-parameters)
  * Dapper intentionally  has no support for `SqlConnection` management; FSharp.Data.SqlClient encapsulates `SqlConnection` 
  life-cycle including asynchronous scenarios while optionally accepting external `SqlTransaction`.
  
  Following FSharp.Data.SqlClient features are unique:
  
  * Reasonable auto-generated result type definition so there is no need to define it in code
  * This type also comes with `IDictionary<string,obj>` and `DynamicObject` implementation
  * Sql command is just a string for other ORMs, while FSHarp.Data.SqlClient verifies it and figures out input parameters and output types 
  so design-time experience is simply unparalleled
  * Design-time verification means less run-time tests, less yak shaving synchronizing database schema with code definitions, and earliest possible 
  identification of bugs and mismatches
  * `SqlProgrammabilityProvider` lets user to explore stored procedures and user-defined functions right from the code with IntelliSense
  
  
  It is my believe that FSharp.Data.SqlClient comes closest to the mission of micro-ORM - to make conversion between data stored in database and .Net run-time types as painless as possible 
  while keeping away from [object-relational impedance mismatch](http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch)
  as described in famous blog [The Vietnam of Computer Science](http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx) by Ted Neward.
  
  [Generating strongly typed DataSets](http://msdn.microsoft.com/en-us/library/wha85tzb.aspx)
  -----------------------------------------
  
  Using strongly typed DataSets requires creation of XSD schema which then used to generate C# code. Dubious pleasure of hand-crafting XSD aside, 
  this traditional technique suffers from the same limitation as Entity Framework and such when compared to FSharp.Data.SqlClient:
  no design-time interaction with model database - it is up to a user to keep definitions and database schema in sync.
  
  
negative.code: A comparison on SQL Server data access methods
  ==============================================
  
  Type providers + Query Expressions
  -----------------------------------------
  
   F# Query Expressions (aka LINQ 2.0) is lovely and useful technology. It makes writing data access code a pleasant exercise.
   There are several different implementations available: [SQLProvider][sql] (recent community effort), [SqlDataConnection][linq2sql]/[DbmlFile][dbml]
   and [SqlEntityConnection][ef]/[EdmxFile][edmx].
  
   But I would like to point out some reasons you might prefer SqlCommandProvider over those.
   Take a look at this  [StackOverflow issue][soissue]. There are dozens of similar questions (hundreds if you include C# LINQ which is essentially
   the same issue).
  
   So, what's a deal? The thing is, you can have perfectly valid F# code that compiles but still fails at run-time because of
   unsupported F#-to-SQL translation semantics. Contrary, SqlCommandProvider offers "What You See Is What You Get" approach.
   Once F# code involving SqlCommandProvider passes compilation stage you are guaranteed to have valid executable (both F# code and T-SQL).
  
   Lack of control and opaqueness of F#-to-SQL conversion spells performance problems too.
   At times developers are really frustrated by ineffective T-SQL code generated by type providers (most of EF users are aware of this issue).
   Evolution and changes in T-SQL code generated by type provider may present certain problems too.
   A data access code that is performing well today can become suboptimal tomorrow.
   SqlCommandProvider gives you direct access to full power of T-SQL scripting including the latest features which are often
   unavailable in type providers because they target older or different versions of the system.
  
     [sql]: http://github.com/fsprojects/SQLProvider
     [linq2sql]: http://msdn.microsoft.com/en-us/library/hh361033.aspx
     [dbml]: http://msdn.microsoft.com/en-us/library/hh361039.aspx
  