Wątek: System zadań w grze.

Ale baza danych W TYM przypadku (i przy takim rozwiązaniu) nic nie daje. Główna zaleta relacyjnej bazy danych to możliwość używania kluczów obcych do wyciągania wszystkich potrzebnych danych w jednym zapytaniu. Jeśli mamy relację o polach:
- idZadania
- typZadania
- par1
- par2
...
- parN
to nie mamy możliwości użycia mechanizmu łączenia tabel. Bez przetwarzania w aplikacji nie wiemy czym jest parK: czy jest to numer potwora czy ilość grzybów do zdobycia. Nie jesteśmy więc w stanie wyszukiwać ani łączyć tabel, po parK. Tak więc moim zdaniem to cała kombinacja (typ zadania + parametry) jest w bazie danych wartością elementarną. Tak już jest, że relacyjne bazy słabo nadają się do odwzorowywania obiektów.

@Drikam: A co jeśli zadanie ma słowny opis, tzn jakąś historyjkę? A co jeśli ta historyjka zawiera znak "-"? To co chcesz zrobić można wygodnie i bezpiecznie zrealizować serializacją tablicy, więc po co wymyślać koło na nowo?
I dlaczego NIGDY nie trzymać w bazie potworów? Jeśli chce udostępnić adminowi możliwość dodawania nowych potworów, lub modyfikowanie ich przez graczy to baza danych jest najwygdniejsza i nie oznacza wcale tak dużo zapytań (1-2 na rządanie).

Zamieszczone przez matips

Ale baza danych W TYM przypadku (i przy takim rozwiązaniu) nic nie daje. Główna zaleta relacyjnej bazy danych to możliwość używania kluczów obcych do wyciągania wszystkich potrzebnych danych w jednym zapytaniu. Jeśli mamy relację o polach:
- idZadania
- typZadania
- par1
- par2
...
- parN
to nie mamy możliwości użycia mechanizmu łączenia tabel. Bez przetwarzania w aplikacji nie wiemy czym jest parK: czy jest to numer potwora czy ilość grzybów do zdobycia. Nie jesteśmy więc w stanie wyszukiwać ani łączyć tabel, po parK. Tak więc moim zdaniem to cała kombinacja (typ zadania + parametry) jest w bazie danych wartością elementarną. Tak już jest, że relacyjne bazy słabo nadają się do odwzorowywania obiektów.

Po co rozdzielac ta tabele na wiele fragmentow skoro i tak musimy wyciagac WSZYSTKIE dane dotyczace zadania zeby okreslic czy faktycznie zostalo wykonane albo w jakim jest punkcie. Nie widze sensu rozbijania tego na wiele tabel poniewaz stan zadania powinna okreslac JEDNA tabela i kropka. parN to tylko DANE trzymane w tabeli dotyczace zadania. Nic nie stoi na przeszkodzie zeby byly typu tekstowego. To plik PHP ma wiedziec jak rozszyfrowac STAN naszego zadania a same parametry sa okreslane tylko po to, aby bylo mozliwe przetwarzanie wielu zadan jednoczesnie. Zadania sa jedna z czesci gry ktora powinna byc cachowana i pozostaje jedynie kwestia wygody przetrzymywania tych danych. Moim zdaniem najwygodniejsze jest zapisywanie tego w jednej tabeli z konstruktorem ktory by to ogarnial. Oczywiste jest tez ze nie bedziemy odpytywac za kazdym razem bazy poniewaz od tego mamy SESJE w ktorej trzymamy informacje niezmienione odnosnie zadania.

Trzymanie potworow w bazie danych jako statyczne dane tez MA SENS. Uzywamy w tym wypadku czegos o nazwie memcache co jest idealnym narzedziem do slownikowania statycznych danych i wykonujemy to tylko raz przy restarcie serwera. memcache jest znacznie szybszy od odczytow z plikow poniewaz uzywamy pamieci RAM do przechowywania konkretnych danych.

PS matips poprzedni post nie byl pojazdem na ciebie tylko zwroceniem uwagi ze zbaczasz z tematu w strone dywagacji