one character of data

  • Although QOD is often described or answered in slightly broken English that suggests a location requiring nchar, I think there are more locations that don't than some people are imagining. And nchar apparently has a greater cost than char, in bytes used, although this can be deceptive. I once ran some tests comparing performance of int, smallint, tinyint, bit (on 2000 I think), and I guess thanks to 32-bit computing, I only found bit worse than all the others. (I therefore prefer tinyint to store any number of bits if performance depends on them. Even though one byte stores eight bit columns, plus another byte if there are NULLs in the table, even if none of my bit columns are NULL.) It wasn't quite a real-world trial.

    I could believe that fooling around with code pages and reconciling them makes nchar generally more efficient than char, but I'd expect to be told that sometime, and I haven't been.

    Also, this is one character. It's unlikely to be text meaningful in itself, it's a code. Even Chinese and Japanese can't say a lot with one Unicode symbol. On the other hand, I've seen them use "Roman" (Latin?) letters for codes.

    http://supports.house.sina.com.cn/decor/stylephoto/yzf/detail.php?id=6000

    I found that with Google. I can only guess what it means. I presume the house is (was) for sale or rent and the lady is not included in the deal. Or maybe she's the housekeeper. (If you're imagining something exciting, it isn't. Well, only very very slightly exciting.) And "A-1" is probably the house address, making my point.

    So I'm saying char(1).

    The specification is for a variable and a lot may be different there, but probably isn't - although I wouldn't really be surprised if char(1) and nvarchar(4000) each consume 8192 bytes of RAM, or even 64k. The mention of nullability is a red herring for a variable. Conceivably I'll use the variable to populate or even create a table column (SELECT @char1 AS column1, n AS column2 INTO tableName FROM ...), and the column type will depend on the variable type. It'll also be nullable, I suppose, but I can ALTER that later.

    I don't think a variable has a code page...?

    Maybe the author didn't even mean a variable, but a column...

  • i think nchar(1) should be the correct answer.. nothing said it was limited to only 1byte characters!

    Using special characters will not work with char(1)

  • I agree: nchar(1) is the most correct answer IMHO so thats what i chose. I lobby for the answer to be changed.

  • The question is too generic about the character entered.

    My choice was nvarchar(1) to cover all posibilities and I think it is the right answer.

  • +1 for nchar(1):

    * The question says nothing about the kind of char to store (ascii vs unicode). I'm not here to think in place of my boss so I go for the safe solution (or I ask him). (Yet, admittedly, I would be surprised if such a column ever stored non-ascii data.)

    * nvarchar(1) has 2 bytes overhead, which are clearly not needed as spaces were explicitly excluded in the question. The question asked for "the best solution": nchar is better than nvarchar so nvarchar is not an eligible answer.

    I want my 1pt back 😉

  • Erratum: I wrote too fast:

    nvarchar(1) has 2 bytes overhead, which are clearly not needed as spaces were explicitly excluded in the question.

    it's of course the fact that we never store 0 chars.

  • Well, i'm surprising by the answer (thought about char(1) or nchar(1), and the answer is nvarchar(1) ?

    MMmmmm... and what about the 2 bytes added in header ?

    I can't agree ! 🙂

    And it's an old question (yes, i go back in past to learn more and more... 😀 ), i'm surprised the answer is not corrected.

    I dismissed the question about july 4th (and its 7 points... yes, i know, indenpendance day but thought it was also link to 'indian costume'/fight the english and reject them to the sea :blush: ), so i want this point ! 😀


    My MCP Transcript (ID : 692471 Access : 109741229)

  • The answer is just authors imagination. - I think you need to clear your basic concepts.

    There is only one correct answer to the question - nchar(1)



    [font="System"]Bhavesh Patel[/font]

    http://bhaveshgpatel.wordpress.com/
  • I agree it should be nchar(1). The question only states one character data and didn't mention any standards.

  • Answer should be nchar(1),if your have wide thinking about your data.

  • i think it should be Char(1). would varchar(1) not occupy 2bytes to store length????

  • (removed - I thought this was in a different discussion)


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • not this is about that question "I have a variable that will hold one character of data and will never be a null or an empty space. Which of the following is the best data type to declare that variable?"

    i am asking regarding that.

    i think i am right. if not please tell me.

  • pankaj upadhyay (8/23/2010)


    not this is about that question "I have a variable that will hold one character of data and will never be a null or an empty space. Which of the following is the best data type to declare that variable?"

    i am asking regarding that.

    i think i am right. if not please tell me.

    For a variable or column that will always be exactly one character long, the best choice is either char(1) or nchar(1), depending on what range of characters have to be supported.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • thanks actually i get confused after reading the ans Either char(1) or varchar(1) may be used. for this question that when we take varchar(1) than will it save length or not.

    anyway thanks again.

Viewing 15 posts - 166 through 180 (of 182 total)

You must be logged in to reply to this topic. Login to reply