Bits

   

The SQL Standard provides two data types for columns that contain bit strings: BIT and BIT VARYING. It also provides one data type for columns that contain "logical" bits: BOOLEAN. Table 7-11 shows the SQL Standard requirements and the level of support (data type and maximum size in bytes) the Big Eight have for these data types.

Table 7-11. ANSI/DBMS Bit Support
    "String of Bits" Data Types "Logical" Data Types
  BIT BIT VARYING BINARY VARBINARY BOOLEAN BIT
ANSI SQL Yes Yes No No Yes No
IBM No No 254 bytes 32KB No No
Informix No No 32KB 2KB 1 byte No
Ingres No No 2KB 2KB No No
InterBase No No No No No No
Microsoft No No 8KB 8KB No 1 byte
MySQL No No No No No 1 byte
Oracle No No 2KB No No No
Sybase No No 8KB 8KB No 1 byte

The word "bit" can mean different things depending on what DBMS you look at, so we've divided the BIT data types into two categories. In Table 7-11, the "string of bits" data types are the SQL Standard BIT and BIT VARYING (with a length argument equal to the fixed and maximum number of bits, respectively) plus the nonstandard SQL extensions BINARY and VARBINARY (with a length argument equal to the fixed and maximum number of bytes, respectively). The values in each of these data types should be just a bunch of zeros and onesraw data that has no meaning to the system. Sometimes people store character data in "string of bits" columns to evade the character set or collation rules associated with a character string data type.

The "logical" data types shown in Table 7-11 are the SQL Standard BOOLEAN and the nonstandard SQL extension BIT. The values in logical columns represent true/false/unknown conditions. It is unfortunate that Microsoft and Sybase call this data type BIT because it is unrelated to the true SQL Standard BIT data type. The correct word really is BOOLEAN.

Notes on Table 7-11:

  • "String of Bits" Data Types columns

    • While IBM does not provide either a BINARY or VARBINARY data type for bit or binary string data, the DBMS provides the same functionality through the FOR BIT DATA attribute. A column defined as CHAR(8) FOR BIT DATA is equivalent to a column defined as BINARY(8), and a column defined as VARCHAR(8) FOR BIT DATA is equivalent to a column defined as VARBINARY(8).

    • Informix's CHAR data type is really a fixed-length "string of bits" type. If you want collations and dictionary sorts, you have to use Informix's NCHAR.

    • Ingres, Microsoft, Oracle, and Sybase all have a binary string data type. Ingres uses the terms BYTE and BYTE VARYING, Microsoft and Sybase call them BINARY and VARBINARY, and Oracle has a RAW data type ( fixed-size only).

  • "Logical" Data Types columns

    • Informix's BOOLEAN doesn't provide full SQL Standard BOOLEAN support, although it does allow you to store three values: 0/1/NULL .

    • The Microsoft/Sybase BIT data type is for logical data but allows only two values 0/1 to be inserted. The SQL Standard logical data type, BOOLEAN, requires support for three values: true/false/unknown .

    • While MySQL does have a BIT data type, it is only a synonym for CHAR(1)a fixed-size character string one character long. This provides no support for bit strings, nor does it provide true support for logical data.

The Bottom Line: Bits

BIT and BIT VARYING are unsupported data types, at least in the SQL Standard style.

BINARY and VARBINARY are handy retainers for data too small to be BLOBs, and too meaningless to be CHARs but are nonstandard SQL extensions. Most DBMSs provide support for binary strings under one name or another.

Recommendation: If portability is a major concern, store bit and binary strings in BLOBs. Use the DBMS's nonstandard binary string data type if space is at a premium.

The BOOLEAN data type is also unsupported in the SQL Standard style. The DBMSs that have a BOOLEAN (Informix), BOOL (MySQL), or BIT (Microsoft and Sybase) data type don't provide true Boolean support.

Recommendation: Take a leaf from MySQL's book. The BOOLEAN data type can be replaced with CHAR(1), which takes the same amount of space (one byte) and requires no conversion effort when used with an API. Add a CHECK constraint to limit the acceptable data, and you'll have betterand more portableBoolean support than is otherwise possible. BOOLEANs will be worth something only when they can operate according to the SQL Standard, which isn't the case now.

   


SQL Performance Tuning
SQL Performance Tuning
ISBN: 0201791692
EAN: 2147483647
Year: 2005
Pages: 125

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net