Co powinno być kluczem - PESEL, czy ID

0

Na studiach wykładowca mówił, że gdy możemy stosowac naturalne klucze główne, to powinniśmy to robić. Z drugiej strony, z tego co wiem, to w Entity Framework muszę mieć sztuczny klucz oby ID, by móc utworzyć związek między relacjami. Jak to w końcu jest?

0

Klucz główny = unikalna wartość

To od Ciebie jako od programisty zależy jakie rozwiązanie wybierzesz. Ja już widziałem naprawdę duże bazy danych gdzie pesel był osobną kolumną oprócz kolumny ID która była kluczem głównym. Twój wybór.

To też zależy jak dużą bazę danych masz, bo np. możesz podejść do tego problemu w ten sposób. Numer PESEL to 11 cyfrowa liczba. Zanim w numerach ID dojdziesz to 11 cyfrowej liczby trochę wody w Wiśle przepłynie :) więc może lepiej wybrać ID. Wybierz po prostu rozwiązanie które dla Ciebie będzie wygodniejsze.

2

PESEL się nie nadaje, głównie z tego względu że nie musi być unikatowy. Tzn. w teorii jest, w praktyce zdarzyło się mi osobiście chyba raz że PESEL był zduplikowany dla dwóch osób (urodzone w 1968 roku) - wiadomo, że biurokracja działa różnie.

7

Biorąc pod uwagę że niedługo będziemy żyć w czasach RODO, to ja bym kompletnie nie brał już pod uwagę naturalnych kluczy które jednoznacznie identyfikują daną osobę jako możliwa opcje.

1

PESEL to kiepski klucz główny, go jak masz osoby z zagranicy to one nie maja numeru PESEL, wiec musiałbyś tam wpisać jakieś sztuczne id, które nie byłyby zduplikowane. Imo dla encji typu nabywca/dostawca sztuczne klucze sa Ok.

6
Zakręcony Karp napisał(a):

Na studiach wykładowca mówił, że gdy możemy stosowac naturalne klucze główne, to powinniśmy to robić. Z drugiej strony, z tego co wiem, to w Entity Framework muszę mieć sztuczny klucz oby ID, by móc utworzyć związek między relacjami. Jak to w końcu jest?

Twój wykładowca nie ma racji. Nigdy nie powinno się stosować naturalnych kluczy, a już na pewno nie PESELu.

Ponoć wspomniany przez @wartek01 problem nieunikalności został już naprawiony - ale pewności mieć nie można. Ale wciąż jest drugi, moim zdaniem nawet większy problem - PESEL się zmienia w przypadku zmiany daty urodzenia lub płci (z tą datą urodzenia chodzi oczywiście o korektę w papierach, nie podróż w czasie ;)). Dlatego w niektórych systemach dla firm ubezpieczeniowych czy banków, pesele ludzi są w ogóle trzymane w oddzielnych tabelach, aby móc przechowywać historię peseli klienta. (Jasne, to bardzo rzadki przypadek, ale trzeba być gotowym i na taką możliwość.)

2

Dodatkowo, użycie PESELu ogranicza możliwość skorzystania z programu do ludzi posiadających PESEL. Nawet jeśli w trakcie projektowania systemu takie będzie założenie, to jednak życie pokazuje, że założenia projektu potrafią się zmieniać w trakcie albo w przyszłości. Wyobraź sobie, że po zakończonym projekcie, gdy system działa, żyje i ma setki/tysiące użytkowników, klient przychodzi do ciebie i prosi o umożliwienie rejestracji również nie-Polakom... Na ile to wycenisz, jeśli zrobiłeś z PESELu PK?

No i patrząc pod kątem RODO - użytkownik ma prawo do bycia zapomnianym. W każdej chwili ma prawo zażądać od ciebie usunięcia z wszelkich baz swoich danych osobowych. Co zrobisz w tej sytuacji, jeśli użyłeś PESELu jako PK?

0

ponadto, jeśli w pewnym momencie program będzie używany w innym kraju, to w ogóle nie będą mieć tam peseli.

1

Jeny tabela powinna się składać z ID + wartość. Ja nie wiem kto się dorwał u Was do nauczania baz, ale kogoś kto zaproponował numer PESEL jako PK powinni od razu ucieszyć karą za nieprzestrzeganie RODO.

1 użytkowników online, w tym zalogowanych: 0, gości: 1