A good habit to get into is to explicitly name your constraints. I try to do this when I create tables to be sure that a) I have a PK and b) it’s named the same for all environments.
I can create a PK inline, with a simple table like this:CREATE TABLE Batting ( BattingKey INT NOT NULL CONSTRAINT BattingPK PRIMARY KEY , PlayerID INT , BattingDate DATETIME , AB TINYINT , H TINYINT , HR tinyint ) ;
This gives a primary key, named “BattingPK, that I can easily see inline with the column.
Steve also gives an alternative formulation which works well for composite keys. You can additionally add constraints after the create statement, but if you are creating temp tables and want to take advantage of temp table reuse, constraints have to be created as part of the table (and cannot have names). For additional fun, since SQL Server 2014, you can create indexes as part of the CREATE TABLE statement as well—that was needed to create memory-optimized tables as back in that edition, you couldn’t add new indexes after the fact.