Baza MySQL - budowanie relacji

pytanie zadane 15 czerwca 2015 w SQL, bazy danych przez _a4 Obywatel (1,330 p.)
zamknięte 13 lipca 2015 przez _a4

Baza danych składa się z dwóch tabel: uzytkownicy i kosze

W tabeli uzytkownicy mamy pola: id (primary key, AI), login, haslo, imie, nazwisko, email

W tabeli kosz mamy: id (primary key, AI), jablko, sliwka, gruszka

Każdy z użytkowników dostaje na starcie jeden kosz z pełną zawartością:

jablko = 1

sliwka = 1

gruszka = 1

Gdy użytkownik postanowi zjeść jakiś owoc, to wartość ta zmieni się z 1 na 0 - mam owoc w koszu lub już nie mam.

Pytanie brzmi:

W jaki sposób najlepiej połączyć użytkowników z koszami (stworzyć relacje)?

Mam dwa pomysły:

A) Zdefiniować, że klucz główny tabeli użytkownicy (id) jest kluczem obcym w tabeli kosz (id).

B) Stworzyć tabele relacje: id (primary key, AI), user, kosz i do danego kosza podpinać danego użytkownika.

C) Może jakiś inny sposób?

komentarz zamknięcia: Problem rozwiązany

2 odpowiedzi

odpowiedź 15 czerwca 2015 przez Comandeer Guru (601,110 p.)
wybrane 15 czerwca 2015 przez _a4

Najlepsza

Zdecydowanie A. Mamy relację 1:1, więc można to spokojnie załatwić po prostu kluczem obcym w tabeli kosze.

Sposób B byłby dobry gdybyśmy mieli relację 1:wiele albo wiele:wiele. Wówczas nie dałoby się tego sensownie zrobić przy pomocy klucza obcego w kosze. Inna rzecz, że jakbym już taką tabelę robił to zrobiłbym to ciut inaczej ;) miałbym dwa pola: user, będące kluczem obcym z uzytkownicy i kosz, będące kluczem obcym z kosze. Dodatkowo nałożyłbym klucz UNIQUE na kosz (bo w końcu tylko jeden user może mieć dany kosz). Takie ograniczenia pozwoliłyby nie martwić się o to, że ktoś zapisze nam do bazy głupoty. No ale to jak mówiłem przy relacjach innych niż 1:1 - w Twoim wypadku nie ma co kombinować tylko po prostu dołożyć klucz obcy do kosze

komentarz 15 czerwca 2015 przez _a4 Obywatel (1,330 p.)
edycja 15 czerwca 2015 przez _a4

Załóżmy, że powstanie 3 (trzecia) tabela: sol, z polami: id (primary key, AI) i sol, która będzie przechowywała sól doklejana do do hasza z pola haslo w tablicy uzytkownicy. Czy w takim przypadku nie będzie można użyć sposobu A dla tej tabeli?

komentarz 15 czerwca 2015 przez Comandeer Guru (601,110 p.)

Nie wiem po co wgl chcesz dla soli robić oddzielną tabelę. Trzymałbym ją w tej samej, co użytkowników.

komentarz 15 czerwca 2015 przez _a4 Obywatel (1,330 p.)

Przechowywanie soli w osobnej tablicy nie jest bezpieczniejsze?

komentarz 15 czerwca 2015 przez Comandeer Guru (601,110 p.)

W teorii jest, ale zobacz sobie na format, w jaki PHP zapisuje hasła i który jest "standardem" (tzw. Modular Crypt Format): $algorytm$koszt$sól$hasło

Taki zapis wcale nie zmniejsza bezpieczeństwa hasła - sól jest tylko dodatkową ochroną, która blokuje ataki słownikowe. Jedyny wymóg dla niej jest taki, że ma być unikalna dla każdego hasła.

Co to oznacza? Że jeśli korzystamy z modułu password PHP (czyli duetu password_hash i password_verify a w PHP < 5.5 z password_compat - polecam!) to hasło wraz z solą zapisywane jest w jednym polu. I problem z głowy ;)

No i taki zapis jest o wiele wydajniejszy niż JOIN przy każdym logowaniu.

komentarz 17 czerwca 2015 przez _a4 Obywatel (1,330 p.)

Czym się różni PRIMARY KEY od UNIQUE ?

Znalazłem infomracje:

Indeks unikalny (UNIQUE)
Indeks unikalny służy do wymuszenia na polu wartości unikalnych, czyli żadna wartość w nim wystąpująca nie może sie powtarzać. Indeks unikalny charakteryzuje się dobrą selektywnośca.

Przecież w PRIMARY KEY wszystkie wartości i tak są i muszą być unikalne.