Intrebari

Re: o intrebare

Gherry — Tue, 16 Sep 2008 21:59:09 GMT

In opinia mea, atata timp cat existenta unui CNP duplicat nu afecteaza functionarea sistemului nu cred ca ar trebui sa conteze; pe de alta parte, probabilitatea ca 2 persoane cu acelasi CNP sa ajunga in acelasi sistem informatic (altul decat cel de evidenta populatiei) e destul de mica deci nu ne costa nimic sa fortam sa fie unic.

Eu, personal, nu il tin unic pt ca m-am lovit de multe situatii in care CNP-ul nu este disponibil si nici macar necesar; daca mai tinem cont si de faptul ca e o chestie de introduere de date si ca exista sanse reale sa se introduca gresit (din cate am inteles, din alta discutie, validarea lui nu functioneaza totdeauna asa ca daca incercam aia intram in alta discutie de acelasi gen) mi se pare frectie la picior de lemn sa fortezi sa fie unic.. In concluzie, eu zic ca se merita folosit un sistem care sa avertizeze operatorul in cazul in care nu este valid sau daca este duplicat insa doar cu titlu informativ, nicidecum ca o restrictie (Atentie: exclud din aceasta discutie cazurile cand reprezinta o componenta critica pt desfasurarea activitatii, caz in care e destul de clar )

Plus de asta, consider ca exista elemente mult mai importante si cu incidente mai dese decat CNP-ul cum ar fi felul cum se stocheaza adresele (mai ales ca acum se fac tot mai multe harti digitale si tot mai detaliate) si numerele de telefon.

Re: o intrebare

ignatandrei — Tue, 16 Sep 2008 19:26:15 GMT

B_gd_n[ ]Sahlean:

Întrebarea, este dacă un sistem informatic care gestionează datele unor persoane fizice ar trebui să permită introducerea unui CNP greşit prin faptul că este duplicat (ca în cazul de faţă) ori ba ?

Depinde de specificatii - si, in acest caz, parerea mea este ca NU ar trebui sa permita duplicarea - avind in vedere ca CNP TREBUIE sa fie unic...

Re: o intrebare

B_gd_n[ ]Sahlean — Tue, 16 Sep 2008 18:36:49 GMT

Incredibil! Doi români au acelaşi CNP
Nu şi-a putut încasa alocaţia de stat, nu se poate angaja, nu poate da examen auto, nu se poate căsători şi nici nu-şi poate face un credit. Asta e drama unui tânăr, în vârstă de 21 de ani, din localitatea gălăţeană Matca, al cărui Cod Numeric Personal este identic cu cel al altui bărbat din Făurei, judeţul Brăila.

Pentru Nelu Iacob, CNP-ul a fost o sursă inepuizabilă de probleme. Şirul necazurilor a început în copilărie când era elev de şcoală generală.

Atunci ar fi trebuit să primească alocaţia de stat. Nu s-a întâmplat aşa şi, pentru a descâlci iţele acestei nedreptăţi, tatăl său, Gheorghe, a mers din uşă în uşă pentru a i se explica de ce fiul său nu primeşte banii cuveniţi.

A aflat că alocaţia lui Nelu mergea la Brăila, la un anume Cristian Adrian Radu, născut tot în zona Tecuciului, şi asta deoarece CNP-urile erau identice. Ciudăţenia nu a putut fi explicată la acea vreme de autorităţi.

Şi necazurile au continuat. “Au venit în comună taloanele pentru analizele gratuite. Toţi am primit, dar lui nu i-a venit. La fel, nu se poate angaja, pentru că CNP-ul nu este în regulă, este la fel cu al celuilalt”, spune Gheorghe Iacob, tatăl băiatului.

Examenul pentru permisul de conducere, pe care vrut să-l susţină recent, avea să-i dea noi bătăi de cap lui Nelu din cauza aceluiaşi CNP. După ce a cheltuit bani pe zeci de drumuri la Tecuci şi Galaţi, în cursul cărora a bătut la uşile mai tuturor instituţiilor care ar fi putut să-i ofere o rezolvare, tânărul s-a trezit că avea permis de conducere de un an.

“Când am fost să dau examen, m-au căutat în calculator după CNP. M-au găsit că aveam permis auto de un an. De fapt celălalt are permis, pentru că are acelaşi CNP, dar eu nu mai pot da examen. Am cheltuit o mulţime de bani cu şcoala de şoferi, am primit ofertă să muncesc în străinătate, dar nu am putut pleca din cauza actelor. Nu pot face nimic! Băiatul celălalt am înţeles că e plecat din ţară şi din cauza asta nu se pot face modificările în acte”, ne-a spus ieri indignat Nelu Iacob, care în această ipostază nu poate spera nici măcar să se căsătorească sau să facă vreun împrumut la bancă.

În câteva săptămâni, Nelu Iacob va avea acte în regulă. Autorităţile din cadrul Serviciului de Evidenţă a Populaţiei Tecuci promit că documentele de identitate ale lui Cristian Adrian Radu, cu tot cu CNP, vor fi schimbate, iar tânărul din Matca îşi va câştiga identitatea “numerică”.

Întrebarea, este dacă un sistem informatic care gestionează datele unor persoane fizice ar trebui să permită introducerea unui CNP greşit prin faptul că este duplicat (ca în cazul de faţă) ori ba ?

Re: o intrebare

Diana — Wed, 18 Jun 2008 06:24:13 GMT

Si eu prefer aici o cheie surogat - pe langa chestiunile legate de performanta si argumentele expuse de Remus sunt destul de importrante in acest caz.

Vezi si http://www.sqlskills.com/blogs/kimberly/PermaLink.aspx?guid=bdaee3f7-1e15-414b-b75f-a290db645159

Re: o intrebare

rsocol — Wed, 18 Jun 2008 04:48:43 GMT

CNP-ul poate să fie foreign key (dacă utilizezi chei naturale, care pot fi compuse din una sau mai multe coloane introduse de utilizator) sau poate să nu fie foreign key (dacă utilizezi chei surogat, care sunt constituite dintr-o singură coloană, generată de baza de date):

CREATE TABLE Salariati (
    CNPSalariat char(13) PRIMARY KEY,
    NumeSalariat varchar(50) NOT NULL,
    PrenumeSalariat varchar(50) NOT NULL
)

CREATE TABLE PersoaneIntretinute (
    CNPPersoana char(13) PRIMARY KEY,
    CNPSalariat char(13) FOREIGN KEY REFERENCES Salariati (CNPSalariat),
    NumePersoana varchar(50) NOT NULL,
    PrenumePersoana varchar(50) NOT NULL,
    Relatie char(1) NOT NULL CHECK (Relatie IN ('C','S','P')) -- copil/sotie/parinte
)

sau

CREATE TABLE Salariati (
    ID_Salariat int IDENTITY PRIMARY KEY,
    NumeSalariat varchar(50) NOT NULL,
    PrenumeSalariat varchar(50) NOT NULL,
    CNPSalariat char(13) NOT NULL UNIQUE
)

CREATE TABLE PersoaneIntretinute (
    ID_Persoana int IDENTITY PRIMARY KEY,
    ID_Salariat int NOT NULL FOREIGN KEY REFERENCES Salariati (ID_Salariat),
    NumePersoana varchar(50) NOT NULL,
    PrenumePersoana varchar(50) NOT NULL,
    Relatie char(1) NOT NULL CHECK (Relatie IN ('C','S','P')), -- copil/sotie/parinte
    CNPPersoana char(13) NOT NULL UNIQUE
)

Ambele design-uri sunt posibile, iar dezbaterea despre care e mai bun este nesfârşită. Personal, optez pentru chei surogat, nu doar din raţiuni de performanţă (un int e mai mic şi mai rapid pt JOIN-uri decât un char(13)), cât mai ales de design al interfeţei (e mai uşor să fac un combo bazat pe o coloană int, decât pe una sau mai multe coloane de diverse tipuri). Un lucru important însă, atunci când folosim chei surogat, este să ne asigurăm că am definit şi o cheie unică formată din coloane introduse de utilizator.

Răzvan

Re: o intrebare

ignatandrei — Tue, 17 Jun 2008 22:46:17 GMT

Talkabout:
in concluzie referitor la primul meu topic: CNP-ul pot sa il am Unique key sau foreign key? cum e cel mai bine sa il pastrez?

Nu reusesc sa inteleg de ce ti-ar trebui inca o tabela pentru Foreign.
Ca mai toti de aici, as face o cheie surogat pe tabela persoana, lasind ca atribut/cimp CNP-ul- si l-as declara si pe el UNIQUE ( + index dupa el)

Re: o intrebare

Talkabout — Tue, 17 Jun 2008 15:51:51 GMT

in concluzie referitor la primul meu topic: CNP-ul pot sa il am Unique key sau foreign key? cum e cel mai bine sa il pastrez?

Re: o intrebare

B_gd_n[ ]Sahlean — Tue, 17 Jun 2008 08:31:13 GMT

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.

Re: o intrebare

B_gd_n[ ]Sahlean — Tue, 17 Jun 2008 08:20:45 GMT

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).

Re: o intrebare

rremus — Tue, 17 Jun 2008 06:51:59 GMT

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.

Re: o intrebare

aflorin27 — Tue, 17 Jun 2008 05:53:54 GMT

1. Daca te gindesti sa folosesti acest CNP pentru o tabela cu angajati, ai grija ca poti avea oameni care nu au CNP (ex. cei nascuti in Rep Moldova, care au permis de munca pt Romania). Si atunci pe acest cimp vei avea fie valori nule (deci nici vorba de cheie primara), fie valori in cu totul alt format decit N(13).

2. Procedurile stocate (scrise in PL/SQL in Oracle si T-SQL in MS SQL) difera ca si sintaxa de la o platforma la alta. Pe Oracle este intr-adevar treaba asta cu :old si :new. Pe MS SQL se folosesc pseudo-tabelele inserted si deleted.

Re: o intrebare

ggciubuc — Tue, 17 Jun 2008 03:28:31 GMT

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 !)

Re: o intrebare

Talkabout — Mon, 16 Jun 2008 18:01:34 GMT

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

Re: o intrebare

Diana — Mon, 16 Jun 2008 07:28:34 GMT

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...

Re: o intrebare

ggciubuc — Mon, 16 Jun 2008 07:14:56 GMT

B_gd_n[ ]Sahlean:
Talkabout:
... PL/SQL...
Ce-i aia PL/SQL ?

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