Witam
Pierwsze pytanie, mam nastepujace tabelki:

[ Users ] 
IDUser - PRIMARY KEY
NazwaKonta
haslo
mail
imie
[  Messages ]
IDMessages  - PRIMARY KEY
temat
tresc 
IDUserNA
   statusNA
IDUserOD
   statusOD
)
Uzytkownicy beda mogli sobie przesylac wiadomosci i wymyslilem to w ten sposob ze wszystkie wiadomosci wrzucam do jednego worka i Nadawca(IDUserNA) widzisz u siebie wiadomosc w zakladce (wyslane) bo status statusNA jest ustawiony na (wyslana), odbiorca IDUserOD widzi wiadomosc w zakladce odebrane bo status statusOD ustawiony jest na (odebrana) jezeli obydwa statusy beda ustawione na (usunac) to wiadomosc zostanie usunieta z bazy. Niewiem czy w ten sposob powinno sie przesylac wiadomosci w portalach, jak
y ktos mogl to
zweryfikowac i naprowadzic mnie na dobra droge.

Drugie Pytanie, jak ma wygladac schemat bazy zeby rozwiazac problem zaproszen do grona znajomych ?
[ Invites ]
IDInvite - PRIMARY KEY
IDUserNA - nadawca zaproszenia
IDUserOD - odbiorca zaproszenia

[ Friends ]
IDUser1
IDUser2 i
)
Ja mam to rozwiazane w ten sposob zaproszenia sa przechowywane w Invites, tabelka bedzie sprawdzana pod katem IDUserOD czy ktos jest zaproszny i jezeli sie zgodzi to zapis i przyjacielstwie bedzie zapisywany w tabelce Friends.
Nie wiem czy dobrze mysle troszke namotalem z tym ale moze ktos zrozumie oco mi chodzi.

3 Pytanie, Jezeli wiem ze wiersz 'plec" moze przyjmowac tylko 3 wartosci kobieta meszczyzna, niepodano, to czy musze robic kolejna tabelke "sex" i z tymi wartosciami i referencja poloczyc czy da sie jakos inaczej to rozwiazywac ?.

Pozdrawiam i
Ogromnie z gory dziekuje za chec zrozumienia moich mysli i udzielenia odpowiedzi ..

Co do pierwszego:
Taka konstrukcja utrudni ci wysyłanie jednej wiadomości do wielu użytkowników (będziesz musiał wtedy powielać w bazie wiele kopii tego samego Message). Powinieneś wyrzucić z [Messages] pola IDUserOD i statusOD i przenieś je do nowej tabeli w relacji jeden-do-wielu z [Messages], np.
[Recepients]
IDMessages
IDUser
status

PRIMARY KEY powinien być wtedy ustawiony na obu polach ID jednocześnie (IDMessages i IDUser)

Co do drugiego - podobna historia - nie ma jak zaprosić jednocześnie wielu użytkowników. Nie masz też możliwości przekazania powodu zaproszenia (jakiegoś indywidualnego komunikatu). Wg mnie zaproszenie do grona znajomych, to po prostu specyficzna wiadomość. Zamiast zakładać osobną tabelę [Invites] dodałbym pole Invite typu BOOLEAN do tabeli [Messages] i zrealizował zaproszenia w oparciu o zwykłą wiadomości.

Co do trzeciego, w MySQL masz typ pola ENUM(), wtedy możesz zdefiniować płeć jako pole:
sex - ENUM ('male', 'female', 'undefined')

Jednak nie jest to rozwiązanie zalecane (chociażby ze względu na niemożność implementacji wielu języków). Nie znaczy to, że należy dla tych trzech przypadków od razu tworzyć dodatkową tabelę. Wg mnie to typowy przerost formy nad treścią. Wystarczy dla tych trzech pozycji przypisać wartości liczbowe, które będą powiązane z definicjami stałych po stronie PHP. Czyli w DB definiujesz:
sex - ENUM (0, 1, 2) (albo po prostu INTEGER)

a w php definiujesz stałe i tablice:

[PHP] pobierz, plaintext 
<?php
define('SEX_UNDEFINED', 0);
define('SEX_MALE', 1);
define('SEX_FEMALE', 2);
 
$sex_pl = array('nie podano', 'mężczyzna', 'kobieta');
$sex_en = array('undefined', 'man', 'woman');
 
// wtedy w kodzie jest wszystko czytelne,
// jeśli odczytasz pleć z bazy do zmiennej $sex, to
 
if($sex == SEX_MALE) ... // sprawdza czy delikwent ma jaja
echo $sex_pl[$sex]; // wyświetla ci płeć delikwenta w konkretnym języku.
?>
[PHP] pobierz, plaintext 

powodzenia.