Re: To 'bit' or not to 'bit'...

From: Steve Kass (skass_at_drew.edu)
Date: 12/29/04 

Date: Wed, 29 Dec 2004 15:51:00 -0500

Anith Sen wrote:

>>>No, I didn't. Maybe I misunderstood, though. Whatever it is you think
>>>is not well-defined, could you possibly give a specific example of it?
>>>
>>>
>
>I have no idea what you are asking for since you seem to have misunderstood
>what I wrote. Perhaps examples of how NULLs can invalidate simple integer
>rules or how it can mess up proven mathematical identities?
>
>
>
You said "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
guess you are
saying that neither is "not well-defined." I thought you were saying
that both were not well-
defined.

If nothing fails to be well-defined, it is silly for me to be asking for
an example...

>>>Now I think you are confusing things. There are problems with IDENTITY,
>>>but I don't think what you are saying here is right at all.
>>>
>>>
>
>If physical dependence is not the problem, what problems do you see?
>
>
You can't update a column with the identity property, the identity
values are not inserted without gaps (though there are good reasons
why), you can't use ALTER COLUMN to add or remove the identity property,
identity columns are not constrained to be UNIQUE (though the
documentation suggests it), for example. It's convenient, nonetheless,
but I think it wasn't as well-conceived as it might have been.

>
>
>>>The physical clustering may initially match the clustered index order,
>>>but there is no requirement it must, and if the IDENTITY column is the
>>>first column of the clustered index, there may be a correlation between
>>>identity values and the clustering.
>>>
>>>
>
>There is no need for identity column to be the first column of the clustered
>index. Here is one instance:
>
>CREATE TABLE t ( c CHAR(1) NOT NULL )
>INSERT t SELECT 'x' UNION SELECT 'y' UNION SELECT 'z'
>CREATE CLUSTERED INDEX idx ON t( c ASC ) -- toggle
>ALTER TABLE t ADD idcol INT IDENTITY
>
>
Yes, that is basically what I said. I must have misunderstood what you
meant by this:

"With IDENTITY I do have issues; Esp. when the values are generated
based on the underlying data's physical clustering order as well as it
being non-updateable hardly qualifies it as a part of a clean logical
model."

I understood this as saying the identity values are generated based on
something physical. I don't think that's correct, but it seems like you
didn't say that.

SK

Relevant Pages

  • Re: XP SP2 problem
    ... they have nulls in s_Generation column. ... Is there a cure for this? ... Are you saying that when you manually add a record to a table in ... usenet at dfenton dot com http://www.dfenton.com/DFA/ ...
    (microsoft.public.access.replication)
  • Re: Difference between = and IN
    ... >I misunderstood what you meant in the previous post. ... >strange results if Nulls were present in the records whereas NOT ... (Remove _NO_ and _SPAM_ to get my e-mail address) ...
    (microsoft.public.sqlserver.mseq)
  • Re: Null values
    ... Allen Browne wrote: ... We're saying the same thing, ... "Allow nulls unless you have a ... reason not to", is the same as: "only make fields required, when you ...
    (microsoft.public.access.tablesdbdesign)