Tabele i ich relacje Opcje

[Largo]

Witam,

Mam do napisania komponent, który będzie działał na zasadzie wezwań. Opiszę go dokładnie. Jest pewna grupa użytkowników, która pomaga innej i oni są "zaufanymi" ludźmi. Niektórzy do handlu np. drogocennych itemów potrzebują pewności, że nic się nie stanie ( kradzież ), dlatego postanowiliśmy napisać taki komponent. Ma on pobierać takie dane:

• Nazwa gry
• Hasło do gry
• Nazwa użytkownika w grze
• ID tematu lub temat ( tutaj proszę poradzić co będzie lepsze )
• Powód
• Nazwa krainy ( DropDown )
• Typ krainy ( DropDown )

Oczywiście, skrypt w ukrytych polach pobiera także ID użytkownika, jak i jego imię ( nie ma kluczy obcych, nie ma relacja na poziomie bazy danych, dlatego zapisuje się nazwę, aby potem ją w razie nie znalezienia użytkownika zamienić, inaczej zostanie puste pole ). Wszystkie dane są wymagane! Oto wstępny pomysł.

[SQL] pobierz, plaintext 
CREATE TABLE medi_logs ( 
id int(8) NOT NULL UNSIGNED AUTO_INCREMENT,
medi_id int(8) NOT NULL,
medi_name varchar(255) NOT NULL DEFAULT '',
req_id int(8) NOT NULL,
req_name varchar(255) NOT NULL DEFAULT '',
game_name varchar(32) NOT NULL DEFAULT '',
game_pass varchar(32) NOT NULL DEFAULT '',
user_acc varchar(255) NOT NULL,
topic_id int(8) NOT NULL DEFAULT '0',
reason varchar(255) NOT NULL DEFAULT '',
realm tinyint(1) NOT NULL,
PRIMARY KEY ( id ),
)
 
CREATE TABLE realms (
id int(8) NOT NULL AUTO_INCREMENT,
realm varchar(32) NOT NULL DEFAULT 'Europe Softcore Ladder',
PRIMARY KEY ( id )
)
[SQL] pobierz, plaintext 

Tabela realms służy do pobierania informacji o krainach, dlatego ją podzieliliśmy, chyba słusznie? Proszę o rady, między innymi czy dawać link czy ID ( ID można zweryfikować na podstawie zapytania do DB i wydaje się bardziej bezpieczne ).

PS. Dodałem 3 pola: medi_id ( ID osoby, która pomaga ), req_id ( ID osoby, która o pomoc prosi ), request_status ( status, który oznacza, czy zgłoszenie zostało przyjęte czy nie ). Pole request_status przyjmuje 4 wartości: 0 - nowe żądania, 1 - anulowane, 2 - udane, 3 - odrzucone ( powody będą różne )

PS2. No teraz to i ja widzę, że to powoli sensu nie ma z tymi krainami. W takim układzie wynika na to, że jedna kraina ma 1 typ, a to jest nieprawdą, bo kraina ma 6 typów... Jak podzielić te informacje? Czy je w ogóle dzielić? Sens działania ma być taki, że user wybiera Krainę ( DropDown ), a następnie jej typ, wiec wg. mnie obecny schemat nie ma sensu, ale może się mylę? OK, problem się rozwiązał. Nie dodajemy wielu krain, idziemy na jednej ( Europe ) i w niej dodamy typy.

Pozdrawiam,
Largo

Ten post edytował Largo 21.03.2009, 22:59:54