Buna
O coloana din tabela PERSOANE care va contine codul numeric personal din cartea de identitate poate fi folosita ca Unique Key sau ca Foreign Key? sau ambele?
Pentru cartea de identitate am nevoie de o noua tabela?
Multumesc

O poti folosi ca o coloana cu constangere unique .Coloane poate fi numerica sau varchar chiar,asa am eu tabela personal

---

Secolul XXI ori va fi religios ori nu va fi deloc

multumesc.
de fapt era o intrebare undeva, cu variantele: Unique, Foreign, sau ambele
deci corect e Unique, fara Foreign

mai am inca 2 intrebari:
1. Un trigger PL/SQL declansat de UPDATE poate contine si :new si :old ? sau doar unul din ele?
2. Pot fi definiti mai multi indecsi asociati unei tabele si care sa refere aceeasi coloana?

Ai grija la valorile "NULL". Daca vrei sa pui o constrangere "UNIQUE" pe coloana, nu poti avea acolo mai mult de o valoare "NULL". Deci toata lumea sa aibe buletin...

1. Vezi BOL ---> Using the inserted and deleted Tables

2. O coloana poate "participa" la mai multi indecsi. Totusi, atentie la date, la patternurile de acces si la felul in care indecsii sunt folositi (daca sunt folositi ).

Talkabout:

... PL/SQL...

Ce-i aia PL/SQL ?

Diana:

...Deci toata lumea sa aibe buletin...

Vrei să zici ... certificat de naştere.

Diana:

Ai grija la valorile "NULL". Daca vrei sa pui o constrangere "UNIQUE" pe coloana, nu poti avea acolo mai mult de o valoare "NULL".

Altfel spus - dupa cum a zis si Diana mai sus - o restricţie UNIQUE pe un câmp (sau set de câmpuri) permite şi existenţa unei singure valori nule. In concluzie, daca nu defineste CNP ca fiind cheie primară, trebuie să-l defineşti cu două restricţii (asta dacă în tabelă ai doar romani):

[1] UNIQUE şi

[2] NOT NULL.

B_gd_n[ ]Sahlean:

Talkabout:

... PL/SQL...

Ce-i aia PL/SQL ?

Un fel de T-SQL dar facut pt platforma de bd Oracle.

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Talkabout, e bine sa specifci clar de la inceput niste lucruri - de exemplu faptul ca lucrezi pe Oracle. Aici cei mai multi dintre noi lucram pe platforma Microsoft, deci nu stiu daca te putem ajuta...

ceea ce am intrebat eu in primul topic nu cred ca depinde de ce platforma folosesc. si eu lucrez pe Microsoft. am pus niste intrebari legate de baze de date, independent de platforma folosita

Cred ca nu e nici o problema daca se pun intrebri cu subiecte diverse (undeva pe forum cineva pe acest forum a pus intrebari de MySQL si a primit rspunsuri bune !)

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Folosirea cheilor 'naturale' (http://en.wikipedia.org/wiki/Natural_key) este in general riscanta. Desi tentatia de a le folosii este foarte mare, iata citeva din riscurile pe termen lung:
- unicitatea nu este garantata. CNP este generat de o autoritate in afara controlului tau si aceasta poate face o greseala si sa genereze un duplicat. Sau o persoana se poate prezenta cu un CNP fals. Busniess-ul tau probabil nu este in masura sa urmareasca astfel de cazuri, si nici nu este interesat, si ce se poate intimpla este ca sistemul informatic se blocheaza cind este prezentat cu o astfel de problema. Putin probabil in practica, dar nu imposibil.
- 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.

---

http://rusanu.com

Observaţii pertintente dar ...

rremus:

Folosirea cheilor 'naturale' (http://en.wikipedia.org/wiki/Natural_key) este in general riscanta. ...

. Wikipedia spune că aceste chei naturale sunt chei candidat ("In relational model database design, a natural key is a candidate key"), cu alte cuvinte o cheie naturală şi candidat (pleonasm) nu este automat cheie primară. Chiar şi în situaţia în care aleg pentru tabelă o cheie primară artificială, cheia naturală şi alternativă trebuie totuşi implementată sub o anumită formă (cel mai simplu mod este cel al definirii unui restricţii/index UNIQUE sau se poate alege altă soluţie ...).

rremus:

... iata citeva din riscurile pe termen lung: - unicitatea nu este garantata.

Cu alte cuvinte trebuie să suflu şi în iaurt ? Asta ar presupune să nu călătoresc cu maşina deoarece oricând poate apare un descreierat de pe sens opus care să ... sau ar trebui să evit calătoria cu avionul deoarece ... ?
Conform http://ro.wikipedia.org/wiki/Cod_numeric_personal CNP este unic. Este adevărat că teoretic şi practic pot apare "erori" (CNP-uri duplicate) dar aceste situatii trebuiesc tratate "local" la nivelul sistemului informatic.

rremus:

... Sau o persoana se poate prezenta cu un CNP fals. Busniess-ul tau probabil nu este in masura sa urmareasca astfel de cazuri, si nici nu este interesat, ...

CNP este un cod autodetector de erori, ultima cifra fiind cifra de control. Deci se poate implementa un algoritm de verificare a CNP-ului, fapt care nu exclude în totalitate CNP-urile false (atât timp cât nu avem acces la baza de date a MIRA).

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.