tebbaerty:

Dap cred ca aveti dreptate. Dar motivul pentru care am pus o cheie compusa este ca nu imi trebuia un id ci o cheie compusa pentru a nu permite 2 inregistrari identice cum a dat exemplu persoana de mai sus (acela cu facturile) . Probabil era si alta metoda dar pe moment asa mi s-a parut firesc :D

si int nu are 65.000 ? .. bine normal ca puteam sa folosesc bigint. :D

Ok.
Exemplul cu acea factura nu este bine ales deoarece:
[1] dacă tabela Factura are cheia primară compusă din Serie+Nr factură atunci
[2] tabela ProduseFacturate va avea o cheie externă compusă Serie+Nr factură problemă urâtă (cel puţin de mine dmmpdv) ...

Soluţia pe care o prefer în această situaţie este cea a unei chei primare artificiale în tabela Factură de forma CodFactura
(de tip INT cu IDENTITY(1,1) sau de tip GUID) plus o cheie candidat (conceptual vb.) implementabilă sub forma unui index cu valori unice compus din Serie  si Nr factura:

CREATE TABLE Factura
(
CodFactura INT IDENTITY(1,1) PRIMARY KEY,
Serie VARCHAR(10) NOT NULL,
Nr INT NOT NULL,
Data DATETIME NOT NULL
);
GO

CREATE UNIQUE NONCLUSTERED INDEX Factura_SerieNr ON Factura (Nr,Serie);
GO

INSERT INTO Factura (Serie,Nr,Data) VALUES ('A',1,'2008-01-01');
INSERT INTO Factura (Serie,Nr,Data) VALUES ('A',1,'2008-02-02');
GO

Chiar si combinatia Serie + Nr are anumite probleme.