String values

.NET string values are Unicode, and are converted by TinyORM into either:

• NVARCHAR(4000) if a string value is 4000 or fewer characters long
• NVARCHAR(MAX) if a string value is more than 4000 characters long

However, there are many legitimate reasons to use NCHAR/CHAR/VARCHAR T-SQL types, and TinyORM provides helper methods to explicitly specify the T-SQL string type:

await db.QueryAsync("SELECT @Name", new { @Name = "Stan".CHAR() }); // will send "Stan" as CHAR(8000)

The following string extension methods are available:

• .CHAR() -- which converts to CHAR(8000) in T-SQL
• .NCHAR() -- which converts to NCHAR(4000) in T-SQL
• .VARCHAR() -- which converts to either VARCHAR(8000) or VARCHAR(MAX) in T-SQL
• .NVARCHAR() -- which converts to either NVARCHAR(4000) or NVARCHAR(MAX) in T-SQL

In order to avoid implicit T-SQL type conversion (which can cause existing indexes to not be used, and possibly other negative effects), the simplest approach is to prefer Unicode T-SQL data types whenever possible (NCHAR/NVARCHAR). This will free up .NET developers from the burden of worrying about matching T-SQL and .NET string types in their queries, at the likely cost of T-SQL schema inefficiencies. A highly-efficient T-SQL schema design that always uses perfectly-minimal string types for each scenario will also require vigilant diligence from the consuming .NET developers to explicitly keep .NET and T-SQL string types in sync for optimal performance.

Larger teams dealing with insufficient code review/oversight, inconsistent training or skill levels, and regular turnover are better off with all-Unicode approach (ex. if obtuse lines are clearly drawn in a holy war b/w DBA and Dev teams).