开发者

Type mapping between SQL Server 2008 and LINQ

My question deals specifically with the mapping of numeric types between SQL Server 2008 and the .NET 3.5 Entity Framework.

I work for a corporation that has fairly stringent rules when it comes to designing databases. Said rules are enforced by a DBA who is neurotic about tables not being any larger in size than they need to be. For instance, he insists that where appropriate we keep numeric columns to tinyint and smallint.

The EF maps numeric types like such (SQL Server type on left, .NET type on right):

tinyint -> Byte

smallint -> Int16

int -> Int

bigint -> Int64

My concern arises due to the fact that I've done some reading recently and found that the .NET runtime is optimized to work with Int32. This question on Stackoverflow real开发者_如何学运维ly gets into the guts of it, should anyone want to do a read-up on it.

My question is this: since the EF maps smallint to Int16, should I just get over the optimization issue and use the Int16 member variables in code, or is there some other solution that would allow me to work with the Int32 type in code and still be able to use smallint types in SQL Server? I can think of a solution or two on my own, but they all seem like overkill in the name of "optimization".


If this were LINQ to SQL instead of LINQ to Entities, you could change the type on your mapping, the only issue will be if you end up with a value in there that's bigger than the smallint column can handle (but then that's a whole 'nother issue anyway, I suppose).

But the LINQ to Entities validator doesn't allow that "mismatch."

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜