Posted by Tony Rogerson on 11/26/07 21:12

>
> 1) NULL-able
> 2) More than one column can have the same data type
> 3) Has to take CHECK() constraints
> 4) Appropriate computations can done on it (numeric, string or
> temporal)

> IDENTITY has none of the properties of a data type because it is not a
> data type at all.

IDENTITY is a property that we give to one column in the table in the same
vain that we can only give the PRIMARY KEY property to one column in the
table.

The column that has the IDENTITY property can have all the aspects you speek
of - you are compeltely wrong.

> It is an exposed physical locator attached to a
> table, not a property of a column.

Rubbish, it's the property of the column.

Will you PLEASE RTFM and STOP guessing!

> It is derived from the physical
> storage used on one machine, like pointer chains in the old
> navigational DBs or row_ids or hash tables.
>

What total utter rubbish.

People use IDENTITY successfully for surrogate key and they follow all
Codd's rules for surrogates - but the DB world has moved on from Codd's
original definitions - see Date and others for a start.

--
Tony Rogerson, SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson
[Ramblings from the field from a SQL consultant]
http://sqlserverfaq.com
[UK SQL User Community]


"--CELKO--" <jcelko212@earthlink.net> wrote in message
news:9ee9fc71-1654-43c6-b03d-a738a875e881@w40g2000hsb.googlegroups.com...
>I think that you missed the concept of IDENTITY and the Relational
> Model. A data type in SQL has to:
>
> 1) NULL-able
> 2) More than one column can have the same data type
> 3) Has to take CHECK() constraints
> 4) Appropriate computations can done on it (numeric, string or
> temporal)
>
> IDENTITY has none of the properties of a data type because it is not a
> data type at all. It is an exposed physical locator attached to a
> table, not a property of a column. It is derived from the physical
> storage used on one machine, like pointer chains in the old
> navigational DBs or row_ids or hash tables.
>
>>> For me is important to be 1,2,3,4,5,6 ... because it is important for
>>> the business logic of application, now, I have some random values
>>> instead. <<
>
> What does this mean in your Logical data model? Since it has to
> reference something in the reality of that data model to be a valid
> RDBMS, how do you validate and verify it?
>
> I would guess that you do none of these basic things, but are
> mimicking a sequential tape file application which depends on counting
> records in procedural code. Do you have cursors, too?
>
> The whole idea of SQL is to use sets and declarative code. This is
> probably just the tip of the iceberg and all you will have is more and
> more kludges piled on each other. The thing will run for awhile, but
> it will choke from lack of data integrity or the inability to scale up
> or to port to another platform.
>
> Fix the design, then fix the application.

[Back to original message]