Re: To 'bit' or not to 'bit'...
From: Anith Sen (anith_at_bizdatasolutions.com)
Date: 12/29/04
- Next message: amirmira: "SQL DMO Query Interface Error"
- Previous message: Lasse Edsvik: "Re: Small insert problem"
- In reply to: --CELKO--: "Re: To 'bit' or not to 'bit'..."
- Next in thread: Steve Kass: "Re: To 'bit' or not to 'bit'..."
- Reply: Steve Kass: "Re: To 'bit' or not to 'bit'..."
- Reply: --CELKO--: "Re: To 'bit' or not to 'bit'..."
- Reply: Erland Sommarskog: "Re: To 'bit' or not to 'bit'..."
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 29 Dec 2004 11:59:02 -0600
>> The ANSI X3J programming languages have rules for converting internal SQL
>> data types to their native data types as part of the Standards. NULLs are
>> handled by indicators. However, there is no Standard for BIT in higher
>> level languages that do not support them
The "credit" should go to the genii of the t-SQL type designers, who decided
to use one of the most fundamental terms of computer science for the name of
a datatype. Shame on them.
Apart from the stupidity of choosing the name "bit" for a datatype, SQL
Server can physically store 8 or fewer bits as a single byte for
optimization reasons. However this physical implementation of a bit datatype
is entirely separated from the logical datatype in exactly the same way as
for other t-SQL datatypes.
Is using the name bit for a datatype confusing? Yes. Non-intuitive? Yes.
Hardware oriented? As much as any other datatype in t-SQL.
>> But more than that, there is no standard or reasonable way I can see to
>> have a BYTE whose third BIT is a NULL.
Consider an integer datatype with a type constraint limiting the values to 1
and 0. Do you find a reasonable way to get around NULLs?
>> I find the idea that bytes are not made from bits strange. I also find
>> that doing byte operations with a NULL bit in the BYTE to be really
>> strange -- What is an exclusive OR on NULLs? What is a two-complement
>> addition? A ones-complement addition?
Bit-wise operators are not well defined on bit datatype with NULLs as much
as integer operators are not well defined on a INT datatype with NULLs. I am
surprised you find NULLs strange with a bit but not with INT.
>> How did you define shift, carry and other basic bit level operations?
We don't. The t-SQL datatype bit has two values. It is null-able just like
any other t-SQL datatypes – one might find this illogical but so does all
SQL datatypes. It has a specifier operator. Being proprietary, it has a
vendor defined external numeric representation. Being a valid type, it has
pre-defined type constraints including one which prohibits all SQL
aggregations except COUNT.
But of course, it has a name to confuse -- bit. And it only exposes the
physical model as much as any other datatypes do.
>> Again, bits and bytes are too low level to be used in SQL. You are
>> mixing physical implementation with the logical model.
No, I am not mixing anything new that was not already being mixed. At least
I can see the weakness of the language and absurdity in selecting a poor
name for a type.
On the other hand, you seem stubborn to agree on SQL's laxity and lack of
logic which allows a type-less marker to be part of a type definition, just
because the standards says so. And, arguing on the silliness of the chosen
name with logical/physical mix-up is not helping either.
-- Anith
- Next message: amirmira: "SQL DMO Query Interface Error"
- Previous message: Lasse Edsvik: "Re: Small insert problem"
- In reply to: --CELKO--: "Re: To 'bit' or not to 'bit'..."
- Next in thread: Steve Kass: "Re: To 'bit' or not to 'bit'..."
- Reply: Steve Kass: "Re: To 'bit' or not to 'bit'..."
- Reply: --CELKO--: "Re: To 'bit' or not to 'bit'..."
- Reply: Erland Sommarskog: "Re: To 'bit' or not to 'bit'..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
