 Klucz obcy - pytanie |
  |
| Klucz obcy - pytanie |
 
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 44 Pomógł: 0 Dołączył: 26.06.2014 Ostrzeżenie: (0%) 
 |
Witam!
Załóżmy, że mamy dwie przykładowe tabele: Klient i Zamówienie. Tabela Klient ma pola: Id, Nazwisko, PESEL, Adres a tabela Zamówienie ma pola: Id, PESEL_klienta, Nazwa towaru, Cena, Metoda płatności. Pola Id są kluczami głównymi w obu tabelach. Czy w tym przypadku pole PESEL może być kluczem obcym w tabeli Zamówienie czy też klucz obcy w jednej tabeli musi koniecznie być kluczem głównym w innej? |
 |
 
|
|
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 6 806 Pomógł: 1828 Dołączył: 11.03.2014 Ostrzeżenie: (0%)
|
PESEL może być kluczem obcym, choć nie jest głównym w tabeli Klient.
Ale bardziej popularne jest łączenie relacją klucz główny-klucz obcy. W Twoim przypadku powinieneś założyć klucz obcy w tabeli Zamówienie o nazwie Id_Klient, a pozbyć się pola PESEL_klienta. |
|
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 1 707 Pomógł: 266 Dołączył: 3.07.2012 Skąd: Poznań Ostrzeżenie: (0%)
|
Dlaczego w zamówieniach przechowujesz PESEL klienta, a nie jego ID? Nie zgadzam się z @trueblue, że PESEL może być kluczem. Byłby to błąd projektu bazy danych, bo PESEL wbrew pozorom nie jest wartością stałą. Jeśli zdecydujesz się na zmianę płci, otrzymujesz nowy PESEL (serio) (IMG:style_emoticons/default/biggrin.gif) A poważniej, PESEL jest prawie-dobrym kluczem, ale mimo wszystko jest to tylko porcja danych. W numerze PESEL mogą zajść błędy. Klucz z definicji powinien być kompletnie transparentny, dlatego lepiej byłoby zmienić strukturę bazy i używać ID klienta. Albo ewentualnie, jeśli PESEL rzeczywiście jest tą porcją danych, która decyduje u Ciebie o unikalności jednostki, jak na przykład naliczanie podatku dla danego numeru PESEL (w co bardzo wątpię), to wtedy lepiej byłoby utworzyć tabelę z PESEL-ami i przypisywać je do użytkowników, a dany PESEL linkować po ID (nie po PESEL-u) do czego trzeba.
|
|
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 18 Dołączył: 5.01.2007 Ostrzeżenie: (0%)
|
I do tego dochodzi jeszcze, tak głośno ostatnimi czasy głoszona, kwestia ochrony danych osobowych.
Nr PESEL jest zestawem danych, który jednoznacznie identyfikuje osobę, więc jej przechowywanie podlega pod ustawę o ODO, a od maja RODO, gdzie sankcje za przetwarzanie bez zgody lub nieodpowiednio chronione dane, są znacznie wyższe. Dlatego w tym przypadku masz już dwa argumenty za tym, żeby nie robić z nr PESEL klucza. |
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 6 806 Pomógł: 1828 Dołączył: 11.03.2014 Ostrzeżenie: (0%)
|
Klucz nie musi być widoczny dla użytkownika zewnętrznego.
|
|
|
|
|
Post
#6
|
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 18 Dołączył: 5.01.2007 Ostrzeżenie: (0%)
|
Tak, masz rację, ale samo posiadanie w bazie tych danych to już przetwarzanie, a o tym mówi ustawa.
|
|
|
|
|
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 6 806 Pomógł: 1828 Dołączył: 11.03.2014 Ostrzeżenie: (0%)
|
Cytat(pianta_d @ 3.03.2018, 17:23:44 )  Tak, masz rację, ale samo posiadanie w bazie tych danych to już przetwarzanie, a o tym mówi ustawa. Co nie ma związku z tym, czy pole jest kluczem czy nie. |
|
|
|
|
Post
#8
|
|
|
Grupa: Zarejestrowani Postów: 176 Pomógł: 18 Dołączył: 5.01.2007 Ostrzeżenie: (0%)
|
Absolutnie masz rację, dyskusja czysto akademicka.
Pozdrawiam |
|
|
|
|
Post
#9
|
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%)
|
Ja nie widzę przeciwskazania żeby PESEL był FK.
Co do argumentu że PESEL może się zmienić to wtedy jest nowy użytkownik z nowym numerem. Co do tego że FK powinien mapować na PK... dobrze by było ale nie musi, choć to jest dublowanie informacji, poza tym w zależności od wielkości bazy PESEL przez dłuugi czas może być dużo cięższym indeksem (zajmoać więcej miejsca) niż PK. Reasumując, Może być. |
|
|
|
|
|
Aktualny czas: 21.09.2025 - 02:53 |
