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ł.

  1. CREATE TABLE medi_logs (
  2. id int(8) NOT NULL UNSIGNED AUTO_INCREMENT,
  3. medi_id int(8) NOT NULL,
  4. medi_name varchar(255) NOT NULL DEFAULT '',
  5. req_id int(8) NOT NULL,
  6. req_name varchar(255) NOT NULL DEFAULT '',
  7. game_name varchar(32) NOT NULL DEFAULT '',
  8. game_pass varchar(32) NOT NULL DEFAULT '',
  9. user_acc varchar(255) NOT NULL,
  10. topic_id int(8) NOT NULL DEFAULT '0',
  11. reason varchar(255) NOT NULL DEFAULT '',
  12. realm tinyint(1) NOT NULL,
  13. PRIMARY KEY ( id ),
  14. )
  15.  
  16. CREATE TABLE realms (
  17. id int(8) NOT NULL AUTO_INCREMENT,
  18. realm varchar(32) NOT NULL DEFAULT 'Europe Softcore Ladder',
  19. PRIMARY KEY ( id )
  20. )


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