How the "Ignore constraint and index names" options differ

The "Ignore constraint and index names" option ignores the names of system generated and user-defined indexes, foreign keys, primary keys, and default, unique, and check constraints when comparing views, tables, and table-valued types, as long as only the name differs. If an index or constraint differs in any way other than its name, its name is not ignored when you deploy.

The "Ignore system named constraint and index names" option works the same way, but only for system generated indexes, foreign keys, primary keys, and default, unique, and check constraints.

To clarify what we mean by "system generated" objects, and to show the difference between the two options, here's a simple example.

Create this table in two test databases:

CREATE TABLE dbo.Author ( 
AuthorID INT NOT NULL PRIMARY KEY, 
AuthorFName VARCHAR(30) NOT NULL, 
AuthorSurname VARCHAR(30) NOT NULL, 
StillActive CHAR(1) DEFAULT 'Y' NOT NULL 
)

The above creates two system constraints, one for the primary key and one for the default constraint. With both ignore options, "Ignore constraint and index names" and "Ignore system named constraint and index names," turned off, the comparison correctly identified the dbo.Author table as existing in both databases, but flagged it as different because the system names differ, as shown in the screenshot below:
 


In this very simple example, enabling either "Ignore constraint and index names" or "Ignore system named constraint and index names" makes the dbo.Author tables identical, as the system generated constraint names are omitted:


 
So in the above simple example, having the "Ignore system named constraint and index names" option enabled appears pointless, as the behaviour of the "Ignore constraint and index names" option is the same.

Now consider this table, which has both system and user-defined names for constraints and an index.

In the source database:

CREATE TABLE [dbo].[Article]( 
[ArticleID] [INT] NOT NULL PRIMARY KEY, 
[ArticleName] [VARCHAR](30) NOT NULL, 
[ISBN] [VARCHAR](17) NOT NULL, 
[ArticleDescription] [VARCHAR](300) NULL, 
[AuthorID] [INT] NOT NULL, 
CONSTRAINT FKArticleID FOREIGN KEY (AuthorID) REFERENCES dbo.Author (AuthorID) 
) 
GO 
CREATE INDEX IBSN_idx ON dbo.Article (ISBN) 
GO

In the target database:

CREATE TABLE [dbo].[Article]( 
[ArticleID] [INT] NOT NULL PRIMARY KEY, 
[ArticleName] [VARCHAR](30) NOT NULL, 
[ISBN] [VARCHAR](17) NOT NULL, 
[ArticleDescription] [VARCHAR](300) NULL, 
[AuthorID] [INT] NOT NULL, 
CONSTRAINT ArticleID FOREIGN KEY (AuthorID) REFERENCES dbo.Author (AuthorID) 
) 
GO 
CREATE INDEX idx_ISBN ON dbo.Article (ISBN) 
GO

With both ignore options, "Ignore constraint and index names" and "Ignore system named constraint and index names," turned off, the comparison correctly identified the differences in the dbo.Article table, as shown in the screenshot below:
 

 
If we select the "Ignore constraint and index names" option, both system and user defined constraints and indexes are ignored, as expected. This means the object is listed as identical and isn't included in any future deployment.
 

 
However, while the user may be happy ignoring the system named primary key constraint, they wish to deploy the user defined named constraints.

Turning off the "Ignore constraint and index names" option and enabling the "Ignore system named constraint and index names" option means the system named constraint on the primary key is ignored, but the user defined naming for the foreign key constraint and index created on the ISBN column is identified as different and included in the subsequent deployment.