As the column will hold only English language letters and digits, we don't need the additional bytes required by the national character data types

CREATE TABLE #tmp (id CHAR(10) COLLATE Cyrillic_General_CS_AS)
INSERT #tmp VALUES ('Привет1') -- Russian word for 'hello'
INSERT #tmp VALUES ('Hello2')
SELECT * FROM #tmp

diamondgm (10/16/2009)

---

Firstly, we assume that the average is the result of an even spread (that the average length is in fact 8.5 - we only need an average of 8 for storage to be a moot point in char vs varchar).
Secondly, within SQL Server, the efficiency may be best to use char in that instance, but take in to account the code operations of trimming and I think it becomes debatable.

I agree with you on a purist level, but practically, I would go with varchar still simply for the programmers' ease.

Nice question

diamondgm (10/16/2009)

---

Firstly, we assume that the average is the result of an even spread (that the average length is in fact 8.5 - we only need an average of 8 for storage to be a moot point in char vs varchar).

Secondly, within SQL Server, the efficiency may be best to use char in that instance, but take in to account the code operations of trimming and I think it becomes debatable.

I agree with you on a purist level, but practically, I would go with varchar still simply for the programmers' ease.

hakan.winther (10/16/2009)

---

personally, I would only use char in rare cases unless all the data for the column are equal.

david.howell (10/16/2009)

---

nVarchar can actually use more than 2 bytes for some characters e.g. chinese characters that use 3 bytes.