[PHP/PostgreSQL] Rejestrowanie użytkownika w systemie

0

Zastanawialem sie ostatnio jak rozwiazac rejestracje uzytkownika w systemie. Tylko nie bardzo wiem czy pomysl jest dobry...
Otoz byloby to utworzenie 2 tabel - pierwsza z loginem (w moim przypadku login=mail) i haslem. Druga to konkretne dane uzytkownika - imie, adres etc.

Obie tabele bylyby powiazane, wiec w drugiej bylby klucz obcy - login_id z tabeli pierwszej. Tylko czy przypadkiem nie bedzie to sytuacja gdy jeden login bedzie dostepny dla wielu uzytkownikow?

Mozna to rozwiazac jedna tylko tabela ale wydaje mi sie, ze nie bedzie to zbyt bezpieczne dla danych. Jak to rozumnie rozwiazac na dwoch tabelach? W ksiazce, ktora pozyczylem oraz w internecie znajduje opisy jak rozwiazac rejestracje uzytkownika na jednej tabeli.

0
metal_man napisał(a)

Otoz byloby to utworzenie 2 tabel - pierwsza z loginem (w moim przypadku login=mail) i haslem. Druga to konkretne dane uzytkownika - imie, adres etc.
jakiś argument popierający takie rozwiązanie

Obie tabele bylyby powiazane, wiec w drugiej bylby klucz obcy - login_id z tabeli pierwszej. Tylko czy przypadkiem nie bedzie to sytuacja gdy jeden login bedzie dostepny dla wielu uzytkownikow?
a co ma ilość tabel do tego czy "jeden login bedzie dostepny dla wielu uzytkownikow"

Mozna to rozwiazac jedna tylko tabela ale wydaje mi sie, ze nie bedzie to zbyt bezpieczne dla danych.
ponieważ

0
Misiekd napisał(a)

jakiś argument popierający takie rozwiązanie

No wlasnie tak mi sie wydaje. Choc nie mowie, ze dobrze mysle.

Misiekd napisał(a)

a co ma ilość tabel do tego czy "jeden login bedzie dostepny dla wielu uzytkownikow"

Bazy danych to dla mnie rozwojowa dziedzina. Tak wstepnie analizujac wyszlo mi powiazanie jeden do wielu...

0

jeśli już to jedyna możliwa relacja to 1 do 1. A rozbijanie czegoś co jest w relacji 1 do 1 na kilka tabel mija się z celem bo tworzysz sobie tylko problemy.

0

Hmm... Chcesz rozbić na dwie tabele? Niezbyt dobry przypadek do nauki tworzenia relacji tabel.

Mozna to rozwiazac jedna tylko tabela ale wydaje mi sie, ze nie bedzie to zbyt bezpieczne dla danych.

Jeśli walniesz się w zapytaniu, to i "podwójną" tabelę można położyć, wystarczy że podczas aktualizacji danych (patrz imię, nazwisko, etc) zapomnisz o warunku WHERE - przed pisaniem pod wpływem alkoholu się nie zabezpieczysz.

Sam SQL się nie pogniewa jak dostanie po 15-20 pól w jednej tabeli, bo obsługiwał tabele które miały takich pól 5 razy tyle. Poza tym popatrz na to później ze względu "ekonomicznego". Jednym zapytaniem wybierzesz bez problemu wszystkie dane użytkownika, jeśli masz dwie tabele i zechcesz posiadając login wybrać imię i nazwisko, to musisz zrobić coś takiego:

  1. Wybierasz z tabeli #1 identyfikator usera szukając według loginu
  2. Wykonujesz zapytanie do drugiej tabeli według ID
  3. Po 2 zapytaniach dostajesz swoje dane.

No dobrze, a co jeśli pisząc system masowych prywatnych wiadomości przyjdzie potrzeba pobrania jakiejś danej z tabeli #2 według loginem, w przypadku 100 userów na raz? Masz dwie opcje - wykonać 200 zapytań albo babrać się w pętlach, implodach etc.

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