views:

949

answers:

2

I was creating a table in SQL Server CE and realized it doesn't support varchar.

Looking this up, I found that "non-Unicode text columns (varchar, char, text) and smallmoney are not supported; although nvarchar, nchar, ntext, and money are supported" as stated at MSDN.

Is this true? Why is this, exactly? It would seem that a compact database would support data types that take less bytes to store...I'm assuming it takes more space to save the Unicode characters.

What is the reasoning behind this?

+2  A: 

It's probably because Windows CE is completely Unicode based and all of it's strings are stored that way.

Steven Robbins
+2  A: 

I think they were trying to reduce their deployment footprint and simplify the interface. That and probably trying to avoid having to deploy more versions of the DLLs (unicode vs non-unicode versions).

And yes it is true that they only support Unicode.

But that does not automatically mean it takes 2 bytes to store. You can encode that at the database layer to basically strip the first byte when it is not needed. Many database engines do this as a means of compression on Unicode.

It just means that any entries that do use the two byte set have a slight overhead of an additional marker telling the engine that the sequence is using two bytes. Otherwise a single byte can still be stored to disk, and expanded as a part of the RowData read.

Most compact databases always use a form of runlength compression when they actually put bytes to disk in order to save space. The format you happen to see it in when it comes out from the engine rarely matches what is actually stored on disk.

Jason Short