This is at your discretion.
Both ways are fine, but I find it annoying to work with composite primary keys, because to refer to them as a foreign key, you need both columns. Imagine the chaos to add a new primary column to this table? You will need to add it to all other tables that depend on the old key.
It's also harder to get two variables in the client code, so I'd rather do it like this:
CREATE TABLE Projeto_Funcionario (
id INT IDENTITY (1, 1),
idProjeto INT NOT NULL,
idFunc INT NOT NULL,
CONSTRAINT PK_Projeto_Funcionario PRIMARY KEY (id),
CONSTRAINT UNIQUE_Projeto_Funcionario UNIQUE (idProjeto, idFunc),
/* chaves estrangeiras... */
)
With a UNIQUE CONSTRAINT, you have the same uniqueness assurance you would have with a primary key, and SQL Server still creates an index for these columns.
Now, when trying to do an INSERT on this table, linking the same employee with the same project, the DBMS will point to the violation error of CONSTRAINT.
-- esse primeiro insert funciona
INSERT INTO Projeto_Funcionario (idProjeto, idFunc)
VALUES (1, 1)
-- esse não
INSERT INTO Projeto_Funcionario (idProjeto, idFunc)
VALUES (1, 1)
-- erro: Violation of UNIQUE KEY constraint 'UNIQUE_Projeto_Funcionario'. Cannot insert duplicate key in object 'dbo.Projeto_Funcionario'. The duplicate key value is (1, 1).
See working in SQL SQL Fiddle .