Jak stworzyc obiekt adekwatny do laczonej bazy danych. Opcje

[rahul]

Witam.
Mam takie 2 tabele

Obrazek tabelek

trzecia (dolna tabelke) otrzymuje po wykonaniu zapytania : SELECT a.*, b.name as 'role_name', b.id as 'role_id' FROM gw_admins as a, gw_admin_roles as b WHERE a.id = '$id' AND key_id = '{$_SESSION['gw_admin']}' and a.role = b.id

i teraz moje pytanie. Jak mam sobie kontener na admina gdzie trzymam :

private $id;
private $gw_key_id;
private $username;
private $password;
private $email;
private $role;
private $first_name;
private $last_name;
private $phone;

czy powinienem tez trzymac private $role_id; nie chce robic osobnego obiektu dla samych roli bo mi bedzie nie potrzebny natomiast przy wywolaniu selectAdmin($id) chce znac jego role po nazwie i miec dostep do id tej roli.
Jak to z punktu OOP rozgryzc ? $admin= new Admin(); $admin->getRole()->getId() , jakos tak ?

[LSM]

Ja nie rozbijam w ogóle roli na osobna tabelę. Mam definicje stałych w pliku konfiguracynym config.php dla tych zmiennych np. define('SYSTEM_ROLE_USER', 'user'). Tych stałych używam w kodach, mam wtedy zachowaną czytelność, gdybym w kodzie uzywał numerków to musiałbym zaglądać do bazy aby przypomnieć sobie co, która cyferka oznacza - a głowa nie śmietnik. W tabeli SystemUser mam pole 'role' a w nim już konkretne nazwy 'admin', 'user'. Tabela SystemUser jest na tyle zgrabna, że nie widziałem potrzeby jej rozbijania ze wzgl. na pole 'role'. Obok pola 'role' ma również 'username', 'password', 'registerDate'.
Jeśli chcesz trzymać dane np. adresowe odn. użytkownika wtedy możesz obok tabeli SystemUser stworzyć tabelę PersonEntity, która będzie ogólną tabelą informującą o innych danych użytkownika. Można ją potem wykorzystywać w dowolnym projekcie, który nie wymaga akurat czegoś takiego jak konto użytkownika.