Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Dynamiczna liczba kolumn
Forum PHP.pl > Forum > Bazy danych > MySQL
Yorki
Witam, zabieram się za przepisanie silnka do swojej gry i mam dylemat. Powiem, że to gra w której są obiekty ( planeta, miasto, wioska ) na których mogą być inne ( budynki ) i stacjonować wojska. Do tej pory starałem się unikać pól TEXT w tabelach, ale chcę aby gra była wysoce konfigurowalna i tym samym np. admin może wybrać sobię liczbę surowców.

Np. jeden wybierze, że chce ich 2 (np. drewno, jedzenie ) a inny, że potrzebuje w swojej grze tych surowców 4 (np. żelazo, drewno, jedzenie, złoto ). Logicznym jest, że tabela zawierająca Prime Obiekty ( planeta, miasto lub wioska ), powinna mieć 4 kolumny (INT lub BIGINT) z aktualnym stanem surowców. Ale co jeśli surowce są tylko dwa lub jest ich znacznie więcej?

Myślałem nad rozwiązaniem, żeby tabela miała tylko podstawowe pola po których będę szukał rekordów, a resztę danych wrzucić do jednej kolumny w formacie JSON. Ale jak to wpłynie na wydajność, czas zapytań? Ma ktoś doświadczenie w tego typu problemach? smile.gif

Dodam, że nie zamierzam po polu TEXT ani sortować ani zapytywać.
buliq
widzę 2 opcje:
1. robisz tabelę, w której każdemu adminowi przypisujesz kolumny z nazwami tych surowców (2 albo 4 wiersze), następna tabela która przetrzymuje wartości dla tych surowców, wszystko joinujesz przy pobieraniu
2. robisz 1 tabelę z kolumnami na 100 nazw surowców (lub mniej, dostosujesz sam, możesz też dodać) i surowce nie używane mają wartość NULL
Yorki
Cytat(buliq @ 8.07.2013, 12:22:36 ) *
widzę 2 opcje:
1. robisz tabelę, w której każdemu adminowi przypisujesz kolumny z nazwami tych surowców (2 albo 4 wiersze), następna tabela która przetrzymuje wartości dla tych surowców, wszystko joinujesz przy pobieraniu
2. robisz 1 tabelę z kolumnami na 100 nazw surowców (lub mniej, dostosujesz sam, możesz też dodać) i surowce nie używane mają wartość NULL


I będzie to warte zachodu i szybsze niż w przypadku TEXT?
Damonsson
Cytat(Yorki @ 8.07.2013, 13:38:30 ) *
I będzie to warte zachodu i szybsze niż w przypadku TEXT?

Niewarte zachodu, (chyba) wszystko jest szybsze niż TEXT.


Skoro wielu graczy, może mieć wiele surowców to tworzysz relację wiele do wielu.

I tabele:
Tabela gracz -> id, login, password i inne głupoty
Tabela słownikowa Surowce -> id, nazwa_surowca
i najważniejsza Tabela wiele do wielu zawierająca klucze obce i ilość -> (fk)id_gracza, (fk)id_surowca, ilosc_surowca.
buliq
Dzisiaj twierdzisz że nie będziesz tworzyć zapytań do tego pola, jutro się okaże że szukasz automatu który z jsona zrobi strukturę nowej tabeli ...
Szybsze może nie być (ale testów nie robiłem) ale dane będą w normalnej formie, nie będziesz ich musiał pobrać, przepuścić przez json_decode itp.
mmmmmmm
Cytat(buliq @ 8.07.2013, 13:43:19 ) *
Dzisiaj twierdzisz że nie będziesz tworzyć zapytań do tego pola, jutro się okaże że szukasz automatu który z jsona zrobi strukturę nowej tabeli ...
Szybsze może nie być (ale testów nie robiłem) ale dane będą w normalnej formie, nie będziesz ich musiał pobrać, przepuścić przez json_decode itp.

I będziesz pobierał tabelę ze 100 kolumnami w której tylko 2 będą wypełnione smile.gif
buliq
2 opcja była bardziej ironiczna
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.