June 5, 2009 at 4:43 pm
So, what, we're going to hope that the single character to be stored isn't unicode?
Because with either char(1) and varchar(1), we're going to disallow a whole bunch of unicode characters from being stored. I must have missed that in the question, the part that this particular character to be stored was going to require only one byte of storage.
The question asked "best".
I submit that the 23% of respondents who answered nchar(1) got it right, because I have some "single character" test cases that will fail with char(1) and varchar(1). Or, are we going to consider failing to a store character that can be stored in nchar(1) to be "best".
Fair question, wrong answer.
June 5, 2009 at 7:40 pm
I still think the answer is char(1) since the question clearly suggests that the column will not have empty or null values. In that scenario more than varchar performance wise char would be better.
June 5, 2009 at 8:14 pm
I demand satisfaction! 😀
June 6, 2009 at 9:54 am
Yes this was a poor QOD, for all the reasons stated so far.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
June 7, 2009 at 10:32 am
Char(1) is correct!!
Varchar(1) could be correct, BUT the info of the question gives a not null and not empty constraints, so all the time the field will have a value.
I want my points back!!!
June 8, 2009 at 1:55 am
I think char(1) or nchar(1) could be best but the varchar options are not best
June 8, 2009 at 3:12 am
The question asks for the 'best' type for storing a character. The best type cannot be one which will not work for a large subset of possible characters (ie any Unicode character), therefore the only possible answers must be nchar(1) and nvarchar(1).
If there had been an option to choose both of these then I'd probably have gone for that one, but given that there wasn't then it must be nchar(1) due to space considerations.
June 8, 2009 at 4:12 am
You can add my vote for nchar(1) - the question states one character but does not restrict that to plain old ascii. Given that information it would be highly irresponsible to use char(1) and potentially break whatever application you are building.
One unrestricted not null not empty character - that's practically the definition of an nchar(1) column. To lead you to char(1) the definition would have to include "ascii".
The given answer is more than questionable, it's plain wrong and I'd chastise any developer in my organisation who chose char(1) given such a specification. I'd be happy if they used nvarchar(1) too, but whatever they use, it has to accept a unicode character.
Dave.
June 8, 2009 at 4:30 am
In this kind of poll, i will make my suggestion:
CHAR(1) or NCHAR(1) depending on the set of characters to store. (ASCII or Non-ASCII)
June 8, 2009 at 5:15 am
Toreador (6/8/2009)
The best type cannot be one which will not work for a large subset of possible characters (ie any Unicode character)
Why?
Best Regards,
Chris Büttner
June 8, 2009 at 6:03 am
Christian Buettner (6/8/2009)
Toreador (6/8/2009)
The best type cannot be one which will not work for a large subset of possible characters (ie any Unicode character)Why?
Because if the spec says you need a variable to hold one character of data, then a solution that fails with the majority of available characters cannot be the best. Unless the specificatioon states that you only need to support the ANSII subset of characters, but in this case, it does not.
June 8, 2009 at 7:18 am
Because if the spec says you need a variable to hold one character of data, then a solution that fails with the majority of available characters cannot be the best. Unless the specificatioon states that you only need to support the ANSII subset of characters, but in this case, it does not.
I appreciate the need for NCHAR, but in over fifteen years of database programming and administration I have yet to need to support any foreign language characters. I'd be happy to do it if the need arose, but it hasn't happened. On top of that, in my experience a CHAR(1) data type is used for a short list of status codes, many times simply Y/N. I don't think I've ever seen one that even needed to be case sensitive. I've seen cases where a CHAR(1) can be replaced by a BIT, I have yet to see a CHAR(1) expanded simply because the ASCII character set wasn't big enough.
NCHAR(1) would be highly unusual in my world, so I would never choose it on the basis of these ambiguous requirements. I'm not going to say anyone else is wrong for using NCHAR(1), but CHAR(1) is equally valid as an answer in many environments. Can't we all just get along?
And as far as Hummer being bought by the Chinese, converting CHAR(1) fields to NCHAR(1) will probably be the least of their problems.
June 8, 2009 at 7:56 am
char(1) and varchar(1) are not equivalent. varchar also incurs overhead to store how many characters are being used so a varchar(1) requires more than one byte of storage (3 actually).
June 8, 2009 at 8:10 am
I guess this depends on what “best” means and what kind of data you need to store. It took me a while to decide, but in the end I picked nchar(1) so I could store anything except the mentioned null or empty space. This was a good question in that it made me really think about the differences in the data types, but bad in that there was not quite enough information to make a clear single choice.
June 8, 2009 at 9:21 am
http://msdn.microsoft.com/en-us/library/ms176089.aspx states "Use char when the sizes of the column data entries are consistent."
So char(1) is the recommended answer, although nchar(1) would be safer.
Viewing 15 posts - 76 through 90 (of 182 total)
You must be logged in to reply to this topic. Login to reply