rremus:

- formatul CNP se poate schimba. O lege trecuta in graba poate adauga un RO in mijloc sau cine stie ce altceva. Aplicatia ta devine deodata 'obsoleta' pentru ca foloseste datele CNP ca cheie. Daca CNP ar fi pastrat doar ca un atribut al persoanei, anticiparea unei astfel de schimbari este mai usoara (eg. un cimp varchar in loc de numeric). - in fine cadrul legal legat de CNP se poate schimba oricind. Este foarte probabil ca intr-un viitor destul de apropiat (ani) cerinta de protectzie a CNP-ului sa devina lege, la fel cum s-a intimplat cu Social Security in USA. Aceasta este cea mai serioasa problema, pentru ca un cimp encriptionat nu poate fi folosit ca cheie.

E adevărat că structura CNP-ului poate fi modificată la un moment dat, dar aceasta este deja o problemă de proiectare a sistemului informatic în sensul "flexibilităţii/rezintenţei la modificari" (modificarea regulilor de gestiune / "business rules" în general). După cum se spune, modificare cerinţelor (funcţionale şi nonfuncţionale) este fapt cert, o realitate. Totul depinde de cât de flexibil dorim să fie sistemul informatic pe care-l dezvoltăm, iar flexibilitatea are în general costurile ei. Totuşi probabilitatea de modificare a CNP-ului acuma este mică, fiind posibilă modificarea CNP-ului peste 15/20 de ani. Dacă avem în vedere faptul că durata medie de viaţă a unui sistem informatic este de aproximativ 5 ani ...

În concluzie, soluţia care mi-ar plăcea mie ar fi cea o cheie primară artificială (surogat) plus o restricţie/index UNIQUE pe CNP, problema fiind acuma faptul că voi avea 2 indecşi în loc de un singur index.