Question

Assume that we have two tables: Roles and Reports. And there exists
a many-to-many relationship between them. Of course, the only solution
that comes to my mind is to create a cross-table, let’s name it RoleReport.
I can see two approaches to the structure of that table:

1. Columns: RoleReportId, RoleId, ReportId
   PK: RoleReportId
2. Columns: RoleId, ReportId
   PK: RoleId, ReportId

Is there any real difference between them (performance or whatever else)?

Answer 1

You will need a composite UNIQUE index on (RoleId, ReportId) anyway.

There is no point in not doing it a PRIMARY KEY.

If you do it a CLUSTERED PRIMARY KEY (which is default), this will be better performance-wise, since it will be less in size.

A clustered primary key will contain only two columns in each record: RoleID and ReportID, while a secondary index will contain three columns: RoleID, ReportID and RoleReportID (as a row pointer).

You may want to create an additional index on ReportID which may be used to search all Roles for a given Report.

There would be some point in making a surrogate key for this relationship if the two following conditions held:

1. You have additional attributes in your relationship (i. e. this table contains additional columns, like Date or anything else)
   • You have lots of tables that refer to this relationship with a FOREIGN KEY

In this case it would be nicer to have a single-column PRIMARY KEY to refer to in FOREIGN KEY relationships.

Since you don’t seem to have this need, just make a composite PRIMARY KEY.