[MySQL]Problem z prawidłową strukturą tabel Opcje

[Ulysess]

witam
uważam że mam złą strukturę tabel trzymających informacji o koncie postaci dlatego was proszę o rade jak według was powinno to wyglądać.

Aktualnie:
wszystkie tabele są typu MyISAM

Struktura tabeli konta:
id_konta (auto_increment)
login (UNIQUE)
haslo (tutaj trzymam hasła zakodowane md5
email (char40)
status_konta (tinyint)

Struktura tabeli postac
id (auto_increment)
id_postac (INDEX)
nick (UNIQUE)
energia
level
doswiadczenie
zloto
ost_logowanie


Struktura tabeli postac_t2
id (auto_increment)
id_postac (INDEX)
dane_a
dane_b
dane_c
... itd

Struktura tabeli postac_t3
id (auto_increment)
id_postac (INDEX)
dane_d
dane_e
dane_f
... itd

dane postaci przetrzymuje jeszcze w kilku innych tabelach

Propozycja struktury:

tabele w których są dane konta + postaci zmienić na typ INNODB i założyć klucze obce ?

Struktura tabeli konta:
id_konta (auto_increment)
login (UNIQUE)
haslo (zmienic moze na sha1?)
email (char40)
status_konta (tinyint)

Struktura tabeli postac
id_postac (auto_increment)
id_konta (klucz obcy ?)
nick (UNIQUE)
energia
level
doswiadczenie
zloto
ost_logowanie


Struktura tabeli postac_t2
id_postac (INDEX)
dane_a
dane_b
dane_c
... itd

Struktura tabeli postac_t3
id_postac (INDEX)
dane_d
dane_e
dane_f
... itd


dodatkowo zastanawiam się czy dla danych typu level , doświadczenie , zloto , energia nie utworzyć i nie trzymać tych danych w 4 różnych tabelach , te dane są często wręcz cały czas używane.

proszę o wasze sugestie

[bostaf]

Trudno powiedzieć, czy czy to jest dobrze czy źle. Zależy co się będzie z danymi działo. InnoDB może być faktycznie lepszym rozwiązaniem, bo sporo parametrów będziesz trzymał w tabelach i klucze obce z transakcjami mogą się przydać. Zanim zaczniesz modelować strukturę, poczytaj ile się da o normalizacji baz danych, np na wikipedii: Normalizacja baz danych (ten polski artykuł jest taki sobie; angielski, z zewnętrznymi odnośnikami na dole, jest bardzo dobry). To co napisałeś na końcu, o osobnych tabelach dla levelu, doświadczenia, itd. ma sens, ale tylko wtedy, jeśli z tymi danymi skojarzone są inne, np. data i czas uzyskania levelu.

Rozumiem, że użytkownik posiada jedno konto i w ramach tego konta może zakładać więcej niż jedną postać w grze?

• Czyli Twoja tablica konta wygląda OK.
• Tabela postac - wyrzuciłbym id, a jego funkcję (klucz podstawowy) przypisałbym polu id_postac. Pozostałe pola w tej tabeli też są OK, z ta uwagą o której pisałem powyżej.
  Jeśli chcesz zapisywać coś więcej o danym parametrze, to zrób dodatkowa tabelę. Np level i data uzyskania: tabela postac_level z polami id_postac, level i data (timestamp) i odpowiednimi kluczami obcymi.
  Jeśli jakiś parametr może przyjmować kilka wartości, to zrób osobną tabelę. Np ekwipunek: tabela postac_ekwipunek z polami id_postac, id_ekwipunek z odpowiednimi kluczami obcymi.
• Stworzyłbym dodatkową tabelę konto_postac kojarząca konta z postaciami, zawierająca na pewno pola id_konto i id_postac jako klucz podstawowy, z odpowiedniami kluczami obcymi i może jakimś dodatkowym polem z datą utworzenia skojarzenia (typ TIMESTAMP).

Przed zaprojektowaniem struktury danych trzeba zaplanować co i jak będzie się zmieniało, jakie funkcje mają spełniać dane, w jaki sposób będą manipulowane. Wtedy struktura wyłoni się sama. Typ danych nie jest aż taki istotny (w granicach rozsądku oczywiście bo nie mam na myśli ustawiania varchar(50) na kolumnie zawierającej dane liczbowe), możesz go zmienić w locie jeśli będzie potrzeba (np zmiana algorytmu hashowania z md5 na sha1 czy jakiegoś bardziej wyrafinowanego).

[Ulysess]

To co napisałeś na końcu, o osobnych tabelach dla levelu, doświadczenia, itd. ma sens, ale tylko wtedy, jeśli z tymi danymi skojarzone są inne, np. data i czas uzyskania levelu.

nie , nic z tych rzeczy aż takie informacje nie są mi potrzebne , chciałem te dane trzymać w oddzielnych tabelach ponieważ wydawało mi się że wtedy powinno szybciej działać (taki jakiś tok myślenia)

Rozumiem, że użytkownik posiada jedno konto i w ramach tego konta może zakładać więcej niż jedną postać w grze?

na tą chwile na koncie może być jedna postać ale przebudowa ma temu służyć aby można było mieć więcej
właśnie tak przypuszczałem że w tabelach powiązanych z postacią nie ma sensu trzymania pola ID tylko po to aby było...

jeśli chodzi o ekwipunek itp to do tego mam zupełnie inną tabele która jest zbudowana z ID unikalne przedmiotu , id przedmiotu z listy , id właściciela.

Stworzyłbym dodatkową tabelę konto_postac kojarząca konta z postaciami, zawierająca na pewno pola id_konto i id_postac jako klucz podstawowy, z odpowiedniami kluczami obcymi i może jakimś dodatkowym polem z datą utworzenia skojarzenia (typ TIMESTAMP).

sądziłem że wystarczyło by do tabeli POSTAC dodac pole id_konta i połączyć to kluczem obcym z tabela KONTO id_konta

[bostaf]

nie , nic z tych rzeczy aż takie informacje nie są mi potrzebne , chciałem te dane trzymać w oddzielnych tabelach ponieważ wydawało mi się że wtedy powinno szybciej działać (taki jakiś tok myślenia)

Spoko. Ale to możesz sprawdzić dopiero jak będziesz miał te tabele wypełnione dużą ilością danych. Wtedy będzie można potestować i sprawdzić czy dzielenie tabel ma wpływ na wydajność. Wydajność u odbiorcy zależy zresztą nie tylko od sposobu przechowywania danych ale i od sposobu manipulowania nimi. W tabeli MySQL można utworzyć 4096 kolumn. Nie można jednoznacznie powiedzieć, czy lepiej mieć 1000 kolumn w jednej tabeli czy 500 w dwóch. Generalnie jednak duża ilość kolumn jest sygnałem o potencjalnym braku normalizacji.

sądziłem że wystarczyło by do tabeli POSTAC dodac pole id_konta i połączyć to kluczem obcym z tabela KONTO id_konta

Też tak można i to działa. Bardzo często tak się robi. Ale wtedy, jak dla mnie, rozmazuje się zakres odpowiedzialności tabel. Dlaczego tabela POSTAC ma przechowywać informacje o KONCIE - obiekcie nadrzędnym? W druga stronę byłoby OK, pod warunkiem, że jedno konto miałoby możliwość posiadania tylko i wyłącznie jednej postaci. Tabele łączące - te które linkują identyfikatory z innych - pozwalają utworzyć przejrzystą strukturę.

[Ulysess]

szczerze mówiąc Twoje rozwiązanie zamieszało mi w głowie...
każda postać może należeć do klanu , na tą chwile wygląda to tak że w tabeli POSTAĆ w kolumnie id_klan jak sama nazwa wskazuje trzymam id klanu , id odpowiada polu id_klan znajdujacego się w spisie klanów.
Rozumiem że powinienem to zmienić tworząc pomocniczą tabele w które struktura powinna mniej więcej wyglądać tak:
Tabela klanowicze:
id (autonumerowanie)
id_postac
id_clan
Funkcja (czyli czy np lider , jakas inna funkcja , członek)
date (tutaj trzymał był date wstąpienia do klanu w postaci UNIX -> ogólnie jakie kolwiek daty trzymam w postaci UNIXowiej)



hmm dodatkowo
na tą chwile przy rejestracji we wszystkich tabelach czyli postac_t1 itd są tworzone rekordy dla danego użytkownika -> prawidłowe rozwiązanie ? czy dopiero w momencie gdy użytkownik odwiedzi odpowiednią zakładkę sprawdzane jest czy w danej tabeli istnieje rekord , jeśłi nie jest tworzony

[bostaf]

każda postać może należeć do klanu , na tą chwile wygląda to tak że w tabeli POSTAĆ w kolumnie id_klan jak sama nazwa wskazuje trzymam id klanu , id odpowiada polu id_klan znajdujacego się w spisie klanów.
Rozumiem że powinienem to zmienić tworząc pomocniczą tabele w które struktura powinna mniej więcej wyglądać tak:
Tabela klanowicze:
id (autonumerowanie)
id_postac
id_clan
Funkcja (czyli czy np lider , jakas inna funkcja , członek)

Dokładnie tak, tzn prawie dokładnie Autonumerowany id wydaje się zbędny. Klucz podstawowy powinien być parą id_postac i id_clan. Tabele nazwałbym jakoś bardziej semantycznie, żeby jej nazwa od razu podpowiadała jaką ona ma funkcję, np postac_klan. To jest tożsame z nazwą klanowicz (bo klanowicz to postać należąca do klanu) ale dokładniej interpretowalne dla innych osób, które być może uczestniczą w tworzeniu całego projektu. I od razu taka nazwa podpowiada Coś więcej: ta tabela nie może zawierać informacji o funkcji, bo może się zdarzyć, że jedna postać w jednym klanie będzie pełniła więcej niż jedną funkcję (np: Ulysess: lider, skarbnik i zbrojmistrz, Bostaf: członek i zbrojmistrz). Aż się prosi kolejna tabela postac_klan_funkcja z kluczem obcym z tabeli postac_klan. Ale jeśli założenie jest takie, że jedna postać może być tylko i wyłącznie w jednym klanie, i jedna postać może pełnić tylko i wyłącznie jedną funkcję, to rzeczywiście ta dodatkowa tabela nie jest potrzebna i można dodać pole funkcja do tabeli postac_klan. Wszystko widzisz zależy od zaplanowanej funkcjonalności systemu.

date (tutaj trzymał był date wstąpienia do klanu w postaci UNIX -> ogólnie jakie kolwiek daty trzymam w postaci UNIXowiej)

Maszz MySQL? Baza danych lubi daty w typie danych DATETIME albo TIMESTAMP. Szybciej konwertuje i przeszukuje taki typ danych bo do tego jest zaprojektowana. Wszystkie bazodanowe funkcje daty i czasu (a jest ich sporo) szybciej śmigają ze swoim wbudowanym typem danych. Przechowując daty jako integery musisz najpierw je konwertować (co zajmuje czas) do formatu daty bazy danych i potem przekazywać do funkcji. To tak z mojego doświadczenia. Jeśli budujesz coś od podstaw to wykorzystuj narzędzia zgodnie z ich zaplanowanym przeznaczeniem, unikniesz w ten sposób problemow w przyszłości. Data w bazie danych? Tylko i wyłącznie DATETIME albo TIMESTAMP.

na tą chwile przy rejestracji we wszystkich tabelach czyli postac_t1 itd są tworzone rekordy dla danego użytkownika -> prawidłowe rozwiązanie ? czy dopiero w momencie gdy użytkownik odwiedzi odpowiednią zakładkę sprawdzane jest czy w danej tabeli istnieje rekord , jeśłi nie jest tworzony

Wg mnie teraz jest prawidłowo. Dobrze jest inicjować dane wartościami domyślnymi na samym początku. Upraszcza to np wyszukiwanie bo eliminuje konieczność tworzenia instrukcji warunkowych: czemu nie ma tych danych? bo nie odwiedził zakładki? bo coś się sypnęło? bo ja o czymś zapomniałem? A może odwiedził ale zresetował? A tak, masz wszystkie dane z domyślnymi wartościami i żadnych NULLi w wyniku wyszukiwania.

[Ulysess]

wielkie dzięki za obszerne wyjaśnienia
hmm na tą chwile osoba pełni 1 funkcje ale to może się zmienić w każdym momencie więc może warto lepiej te dane trzymać w dodatkowej tabeli:)

co do ostatniego jest 1 dosyć poważna wada ... wprowadzenie nowej opcji w grze -> nowa tabela dla postaci -> trzeba ręcznie utworzyć rekordy dla istniejących postaci..
ogólnie dzięki za pomoc

[bostaf]

co do ostatniego jest 1 dosyć poważna wada ... wprowadzenie nowej opcji w grze -> nowa tabela dla postaci -> trzeba ręcznie utworzyć rekordy dla istniejących postaci..

Albo wykorzystać triggery. Sam nigdy ich nie używałem więc nie podpowiem jak, ale wykorzystuje się je między innymi do automatycznego wprowadzania danych do tabel.

ogólnie dzięki za pomoc

Nie ma sprawy, sam się przy okazji czegoś nauczyłem