anchor.diff:  
   ### Common for all TypeProviders
   
  -- You write just logic code, not POCO-objects and mappings
  -- If your database changes, your code breaks on compile time
  +- You write logic, not POCO-objects and mappings
  +- If your database changes, your code breaks at compile time
   - No SQL-injection vulnerabilities
   - Commit to existing transactions so you can mix with other technologies
  -- You can call stored procedures if needed.
  -- Supports joins and nested in-queries so you can avoid "n+1 database hits" problems
  +- You can call stored procedures if needed
  +- Joins and nested in-queries are supported so you can avoid "n+1 database hits" problems
   
   ### FSharp.Data.SqlClient
   
   Good:
   
  -- User has control of SQL-clauses
  -- So you can hit database indexes with complex queries
  -- SQL-syntax is already familiar for many
  +- User has full control of SQL
  +- Which allows full utilization of database indexes with complex queries
  +- SQL syntax is already familiar for many
  +- Exposes database objects directly in code
   - Supports async database operations
  -- Use it e.g. for data processing backends
  +- Used in production for enterprise development for years
   - Open source
   
   Not so good:
   
  -- By default supports only Microsoft SQLServer and its SQL.
  +- By default supports only Microsoft SQLServer and T-SQL
   - Code overhead if you have a large amount of different small operations
   - Doesn't generate domain model for work with C#
  -
   
   ### SQLProvider
   
  
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: 
  - Supports any database (MSSQL, MySQL, Postgre, Oracle, Odbc, ...)
  - Changing the database is not actually huge work
  - Makes effective simple SQL
  - Supports async database operations
  - Simplifies user code
  - Open source
  
  Not so good:
  