My second 2 cents :-)
ADD CONSTRAINT [PK_dbo.LogAudit]
Off-topic: I highly recommend NOT to use dot in entities names. The dot character has a meaning/convention of a "child". FOr example X.Y usually mean that Y is a child of the entity X
@DanGuzman-5735: Given this is an audit table rather than a relational table (i.e. no referential constraints), I suggest you don't create a primary key at all.
Who need Keys?!?
Candidate key is a unique identifier of the row/record. A surrogate key is a type of Candidate key which does not have any contextual or business meaning (like "id" for example or uniqueidetifier). A natural key is also a type of Candidate key that has contextual or business meaning. Both may or may not be used as the primary key.
A "Primary key" is one of the "Candidate keys", which is used in the relational model for references to this row in the table. So this is basically true. If your table does not have relations with other tables then you do not need a Primary Key.
There is still need for at least one Candidate key in order to recognize specific row in the table (or record on the disk), but SQL Server take care of this if there is no clustered Index.
Clustered Indexes is something else! Tables without clustered indexes are called "heaps". This can improve INSERT dramatically since there is no need for any order for the records on the disk. The server can simply write the records wherever is the the fastest. Unfortunately, nothing is free and this approach slow any query that need to find the row (select, update, any use of filter or sorting). Heap table might fit for staging tables and Log tables for example. An audit table is usually a type of log table.
Note: SQL Server has a mechanism to identify the physical address of a row. It is undocumented but we can also use this information using "%%physloc%%" like it was a column name (For example select *, %%physloc%%, sys.fn_physLocFormatter(%%physloc%%) from T
) - remember that this value can be changed since it based on the physical location of the row.
back to the original question and the approach you present
You should take into consideration how you use the data before you make any change like removing a column. Dropping the column can impact your application. If you are using this column in any references then you might want to keep the columns data as it is. Removing the primary key and the Clustered Index can be done without removing the column.
Moreover, removing a column (without any other action) will not remove the column under the scenes, and we will even be able to read the data from that column (using undocumented tools) after it was dropped. This is one of the topics which I will demonstrate and explain in my lecture at the data platform summit 2020.