Why to use "not null primary key" in TSQL?

Question

I am seeing too frequently "not null primary key" in scripts creating tables in TSQL in blogs, articles, books, forums, here in SO, etc.

For example, BING gives 630,000 results ((just in English) if to search against "not null" NEAR "primary key" "sql server":
http://www.bing.com/search?q=%22not+null%22+NEAR+%22primary+key%22+%22sql+server%22&go=&form=QBRE&filt=lf

I always perceived "NOT NULL" as inseparable part of definition of PRIMARY KEY, at least in SQL Server.
I tried to create a tables with Primary KEYs with and without "NOT NULL" in SQL Server but could not grasp the possible difference.

Why do all use "NOT NULL" for creating a primary key even in fast (short) illustrations?

---

Update:
How can NULL identify anything or be unique (as well as preventing multiple NULLs if one is permitted)? It is unspecified, missing, not applicable value

My question also implied subquestions:
if one defines "NOT NULL" for PK, why then UNIQUE is not specified?
And what is the definition of PK. IS it UNIQUE CONSTRAINT + NOT NULL or UNIQUE INDEX (then why NOT NULL)?
Plz give me link to msdn docs on it.

Update2: @Damien_The_Unbeliever

Why is not synonym without "NOT NULL"?

CREATE TABLE T3 
(
    PK int -- NOT NULL commented out
    , nonPK int -- to double-check my sanity 
    , constraint PK_vgv8 PRIMARY KEY (PK) on [PRIMARY]
) 

still does not permit NULL giving:

• ---

  Microsoft SQL Server Management Studio

  ---

  No row was updated.

  The data in row 2 was not committed. Error Source: .Net SqlClient Data Provider. Error Message: Cannot insert the value NULL into column 'PK', table 'TestData.dbo.T3'; column does not allow nulls. INSERT fails.

  The statement has been terminated.

  Correct the errors and retry or press ESC to cancel the change(s).

  ---

  OK Help

  ---

Update3:
This, concepts and terms definition, might appear as impractical nuisance.
It is not, some wrong statement (in the opinion of other(s) during communication/discussion) on a basic notion is enough to be considered a moron and create barriers in professional interaction and communication.

I forgot to tell, NOT NULL is scripted by SSMS for PK!

Answer 1

Edited for clarity

According to the SQL Specification, a primary key can not contain NULL. This means that decorating a column with either "NOT NULL PRIMARY KEY" or just "PRIMARY KEY" should do the same thing. But you are relying on the SQL engine in question correctly following the SQL standard. As an example due to an early bug, SQL Lite does not correctly implement the standard and allows null values in non-integer primary keys (see sqlite.org/lang_createtable.html). That would mean for (atleast) SQLLite the two statements do two different things.

As "NOT NULL PRIMARY KEY" clearly indicates intent and continues to enfore non-null values even if the primary key is removed, that should be the prefered syntax.

Answer 2

The following:

CREATE TABLE T1 (
    T1ID int not null primary key
)

is really shorthand for the following:

CREATE TABLE T1 (
    T1ID int not null,
    constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY]
)

The column definition is really quite separate from the constraint definition. It's just that the shorthand hides the fact that it's two separate definitions. (Of course, if you use the long-hand form, you can do such things as defining a primary key across multiple columns).

Edit, in response to update. No, you still cannot have a nullable column in the primary key. But given that it's normal to specify the nullability of each column in a create table statement, it just feels odd to omit it (even though it's implied/required by the PRIMARY KEY constraint).

CREATE TABLE T1 (
    T1ID int,
    constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY]
)

creates exactly the same table as the previous code sample. Explicitly specifying the "not null"-ability of a column is, then, more an explicit acknowledgement of the outcome, rather than a requirement.

And finally, you'll find it frequently occurring in example code because people have developed their database, and then used the built in SQL tools for generating a script from their database - the scripting tools always put everything explicitly.