Geek Answers Handbook

NCHAR (1) vs BIT

I work as part of a database refactoring scheme (SQL Server 2008) and collect arguments to change the columns NCHAR(1)(which store the values Y|N) to BIT. Everyone understands that this is necessary and do not know why this is happening, but this change affects the production database, therefore weighty arguments are required. The table stores the address directory (up to 1 m records).

The first argument I found is that each nchar fields takes 2 bytes, each 8 bits takes 1 byte (the next 8 is an extra 1 byte).

What's next? Perhaps some problems with index performance?

+5
source share
8 answers

The bit field helps your logic by automatically applying what is currently an implicit business rule (that is, this column can only contain “Y” or “N”). If you apply this rule programmatically, you can save by eliminating this overhead. Indexing a bit column by itself is of little importance due to low power, but may be useful as part of a composite index.

See also:

+4
source

- , . .. , , .

, nchar (1) , ? .

/- , , , , * . , , .

+10

NCHAR (1) , Oracle . Oracle Oracle, , Oracle, . Sql .

, , - ( NCHAR (1) Oracle), , datetime, , , , , , , , 4 5 , datetime.

+6

, , nchar (1).

nchar:

  • Y vs Y vs some unicode Y
  • Y N
  • "true" o "false" (, .net boolean)
  • Y N - . Ja/Nein, Oui/Non ..

, .

  • (, CHECK)
  • .

, smilldatetime "WhenInactive" "IsActive". NULL = .

+3

LINQ2SQL Entity Framework, BIT bool, NCHAR(1) string.

+2

Where fld = 'Y'?

, , , .

, , , 1m +, , @Andrew.

+1

:

  • / - , Yes or No, , , , . True/False (T/F), On/Off (?O/F), Open/Closed(O/C) ..

  • - 0 or 1. , *char(1) Y, N, X ☺.

  • , .

  • Re: : ( CHAR) , 0 1. .

( )

+1

I had several cases when we wanted a little field, but could not know for sure that in this field there would never be a need for a third or fourth value. Therefore, we structured it as a string field containing Y or N. Of course, we did this only in very unique situations.

0
source

More articles: