Jednym z podstawowych elementów logiki baz danych są indeksy.
Indeksy służą w uproszczeniu do kilku rzeczy. W skrócie indeksy są streszczeniem najwazniejszych informacji o tabelach - mogą pełnić funkcję czegoś na podobieństwo tablicy alokacji plików. Dobrze zaprojektowana baza to taka baza która jak najwięcej operacji wykonuje na indeksach a nie na samych danych.
Jeśli logika tylko pozwala uczynić coś co jest często używane indeksem unikatowym to należy to zrobić. Indeksy unikatowe po pierwsze przyspieszają wyszukiwanie (jeśli wiesz, że na liście dana pozycja występuje tylko raz to po znalezieniu pierwszego wystąpienia przerywasz szukanie, a jesli byś nie miał takiej pewności musiałbyś szukać do samego końca). Po drugie przyspieszają łączenie tabel w bardziej złożonych zapytaniach. Po trzecie indeksy unikatowe chronią strukturę logiczną bazy przed błędami logicznymi. Tak na przykład w twoim przypadku - nie może być dwóch użytkowników o tym samym loginie - dlatego login powinien być unikatowy.
Indeksy i klucze unikatowe można tworzyć na etapie tworzenia tabeli, mozna też utworzyć je konstrukcją ALTER:
ALTER TABLE `child` ADD UNIQUE (`parent_id`)
Ale jeśli w tabeli będą już zdublowane wartości klucz nie zostanie utworzony.
Zabezpieczanie się przed wprowadzaniem do tabel niepoprawnych wartości można prowadzić też po stronie php (np. w komunikacji z użytkownikiem) ale ochrona samych danych po stronie bazy danych jest nieodzowna w przypadku niewychwycenia błędów przez skrypty php.
Indeksy nie musza być pojedynczymi polami tabeli - mogą być oparte na kliku polach które dopiero razem weryfikowane muszą być unikatowe - np. imię+nazwisko (zarówno imie jak i nazwisko z osobna nie mają podstaw by być unikatowe)
Co więcej ja w moich skryptach obsługi użytkowników wcale nie mam unikatowych loginów. Unikatowy musi byc użytkownik. Użytkownika nie identyfikuje po samym loginie ale po login+hasło. Więc może sie zdarzyć że dwóch użytkowników ma taki sam login ale inne hasła

ale kombinacja login+hasło jest jak najbardziej unikatowa i przypisana do danego użytkownika.
Wreszcie najbardziej zaawansowanym aparatem ochrony integralności danych są FORAIGN KEYS (klucze obce) nadzorujące integralność na poziomie kilku tabel w bazie. Np. klienci - faktury. Klucz obcy zabezpiecza przed wpisaniem do tabeli faktury faktury na klienta którego nie ma jeszcze w tabeli klienci. I odwrotnie. Klucz obcy nie pozwoli usunąć klienta jeśli ma już wystawioną fakturę.
Pozdrawiam