June 5, 2009 at 7:15 am
You can debate whether it should be CHAR(1) or NCHAR(1), but VARCHAR(1) is insane. If I had my way, I'd put a DDL trigger on every database that would disable the login of anyone trying to use VARCHAR(1). Enabling the logins would only occur after a severe beating with the Big Foam Cluebat. :crazy:
And yes, I do want my point back.
June 5, 2009 at 7:16 am
Like many others I got this "wrong". Like many others I chose Nchar(1) since there was no description of ANSI vs International Character sets and varchar(1) takes extra bytes to store.
At the time I wrote this 79% of respondent have chose char(1) or Nchar(1). I'm not saying that majority should always rule, but in this case it probably should.
-Luke.
June 5, 2009 at 7:19 am
This is just one more of these questions that have been put out there without checking/thinking about the possible correct answer.
As we have seen from previous posters, either char(1) or nchar(1) should be the possible answers, depending on were you are or what data you would store.
Once again the question does not define exactly the context for its usage. Boooh!
June 5, 2009 at 7:26 am
Based on the information given, the answer has to be wrong.
There was no information given stating that the single character would not be single byte character.
Since the question went thru the trouble of specifying always single character and never empty or null, then one should be able to safely assume that if there were any other limitation then they would have been mentioned.
nchar and nvarchar are then the only possible answer, with nchar being a better answer than nvarchar.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
June 5, 2009 at 7:29 am
Char(1) should be correct since this will never be empty or NULL
June 5, 2009 at 7:38 am
David Smerchek (6/5/2009)
Char(1) should be correct since this will never be empty or NULL
Have fun loading Unicode characters in your char(1) column!
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
June 5, 2009 at 7:40 am
char(1) should should be correct since it will always have a value. Using char(1) will place the always present data at the front of the table in the non-variable data section. This will mean when it is used without the variable section that block will not have to be load nor will the pointer have to move as far.
And yes I too want my point back.....
June 5, 2009 at 7:46 am
... another vote for NCHAR(1)...
June 5, 2009 at 7:47 am
I love varchar/nvarchar, but for a 1 character field of undertermined character set the only possible answers should be either char(1) or nchar(1). Varchar has no place in a 1 length field.
June 5, 2009 at 7:48 am
Alvin Ramard (6/5/2009)
Have fun loading Unicode characters in your char(1) column!
... well, that's part of the problem, the question did not properly specify the rules of the game..... In my case, for our use I'd have used char(1) as I don't need unicode chars.....
June 5, 2009 at 7:49 am
Definitely nchar. Think multinational.
June 5, 2009 at 7:55 am
I agree, varchar(1) is not a good answer because of the extra 2 bytes of storage. For the smallest I would chose char, for multibyte languages, Nchar. Your mileage may vary.
June 5, 2009 at 8:20 am
Another vote for nchar for all the reasons previously stated!
June 5, 2009 at 8:22 am
Maybe the author of the question used information related to how Oracle stores char(1) and varchar2(1) data. There the space used on disk will be the same.
From a design perspective, using a varchar field in this case is wrong.
June 5, 2009 at 8:33 am
The correct answer is CHAR(1).
Here are the reasons:
VARCHAR(1) should not be used because of the additional overhead involved when using ANY variable definition, since SQL Server has to determine the actual length. Don't think for a second that a VARCHAR(1) only takes one byte, because the length is also stored even though you can't see it. Microsoft and every other DB manufacturer will tell you that you should not use variable definitions where the length is consistant and not null. This is extremely basic IT stuff.
NCHAR(1) should not be used, because it is, again, an unnecessary overhead. ASCII character columns, when used with UNICODE column data in T-SQL, are automatically converted for comparison logic. The only time you should use NCHAR is when you know with absolute certainty that you will be storing characters that do not have equivalence in the ASCII code set. That is a special condition and the question was posed generally.
Unless you work for a multi-national company and actually need it, the use of UNICODE is a huge waste of resources.
Viewing 15 posts - 31 through 45 (of 182 total)
You must be logged in to reply to this topic. Login to reply