Forum webmasterów

Witam..
W ostatnim czasie podjąłem się tworzenia pewnej gry opartej na php, ale natrafiłem na dylemat... Sprawa nie jest skomplikowana i bez odpowiedzi obejść się bym mógł, lecz znacznie lżej by mi się pisało skrypty z wiedzą ile zapytań do bazy MySQL powinno być średnio wykonywanych na jednym wywołaniu strony?
Czy jest jakieś optimum co do ilości wykonywanych zapytań? Ile średnio na Waszych stronach jest ich wykonywanych? I czy jest jakaś granica ilości zapytań, taka by działanie serwisu nie sprawiało problemów?
(W skrócie: ile mogę wykonać zapytań przy jednym wywołaniu strony, by nie przesadzić?)
Rozumiem, że jak najmniej oznacza jak najlepiej, ale to nie jest prostej budowy technicznej strona. Aa.. I byłbym wdzięczny, za nie odsyłanie mnie do google.pl. To nie jest sprawa na które można znaleźć tak po prostu odpowiedź nie pytając innych, jak u nich ta sytuacja wygląda. A zresztą szukałem i nic ciekawego nie znalazłem . A i chciałbym nadmienić, że nie chodzi mi o żaden licznik do liczenia zapytań - taki napisałem już i przez to trafiłem tutaj ;P.
Pozdrawiam.

Witaj,
odpowiedź jest bardzo prosta i zapewne mało satysfakcjonująca dla Ciebie. Zapytań powinno być tylko tyle ile jest absolutnie konieczne.
Czemu taka odpowiedź ? Po pierwsze dlatego że tak na prawdę tych zapytań może być nawet kilka tysięcy jeżeli ze strony będziesz korzystał tylko Ty. Jak ze strony będzie korzystało 100.000 ludzi to jedno zapytanie od jednego usera wygeneruje ich 100.000 niemalże w jednym momencie (zakładając że każdy kliknie na jakiś link i przejdzie na stronę gdzie zostanie wykonane zapytanie). Do tego dochodzi prędkość i ustawienia serwera no i dla gier raczej powinien być to serwer dedykowany. No i od razu wybij sobie z głowy serwery na Windowsie.

Poza tym pamiętaj że zapytania trzeba wykonywać z głową. "SELECT * FROM users" na pewno jest przydatne przy przeglądaniu tych userów ale jeżeli jest ich kilkanaście tysięcy to z deka zajmie to miejsca i przy większej ilości takich zapytań serwer po prostu się zapcha (RAM nie jest nieskończony, to nie maszyna Turinga) Znowu pamiętaj że w jednym zapytaniu pobierać można dane z kilku tabel, pamiętaj jednak żeby odpowiednio porcjować takie dane.

Dzięki, chociaż nadal trwam w dylemacie, choć już nieco mniejszym . Odpowiedź rzeczywiście nie jest dla mnie do końca satysfakcjonująca, bowiem szukałem punktu wyjścia w doświadczeniu innych programistów i ich wynikach w generowanych zapytań. Dałeś mi jednak do zrozumienia, że ów optimum którego szukałem jest zależne od tylu czynników, że praktycznie nie istnieje jedyna jednoznaczna odpowiedź.
Tworząc tą grę zakładam, że będzie z niej korzystać maksymalnie 500 graczy, z czego średnio jednocześnie zalogowanych będzie do 30 (zakładam, czy marzę o tym? ). Jakkolwiek jednak zapytań będzie wiele nie martwił bym się o wydajność serwerów, szczerze mówiąc, nie jest to nawet moje zmartwienie..

Heh no tak, usługi hostingowe tylko wyłącznie na Linuxie. W domu mam oczywiście Windowsa i przez to niemałe tęsknoty do Crona, a oprócz tego również posiadam serwer na kompie Mac Pro - strasznie zagmatwany system zarządzania serwerem, który z założenia ma być prosty.. Ale nie o tym miałem mówić.
Chciałbym jeszcze zapytać, (wiem, wiem, jednoznacznej odpowiedzi nie ma) jaką liczbę byście podali, jako Wasze optimum wykonywanych zapytań?

Pozostaje kwestia o jakiej ilości danych mówimy, jakim serwerze oraz co chcesz zrobić.
Co z tego że powiem Ci np że najwygodniej było by wykonać max 5 zapytań skoro serwer przy 30 osobach wytrzyma nawet 500 ? Co z tego że powiem Ci że wytrzyma 500 skoro zaloguje się 50 osób i połowa z nich dostanie błąd serwera ? Wyczerpany limit połączeń ?

Ustawienia serwera decydują o maksymalnej ilości połączeń.
Serwer decyduje o tym jak duża ilość danych może być przechowywana w pamięci RAM.
Skrypt decyduje ile tych zapytań trzeba wykonać.
Gotowy skrypt pokaże które zapytania są niezbędne, które można pominąć i wpleść je w inne zapytania a które zapytania trzeba rozdzielić gdyż pobierają na raz za dużo danych.

Teraz możemy sobie gdybać ile nam się podoba. I tak dobrej odpowiedzi nie otrzymasz. Po prostu ogranicz zapytania do niezbędnego minimum i nie pobieraj za dużo danych na raz. Atrybut LIMIT dla zapytania SQL będzie tym co będziesz stosował niemal wszędzie więc dobrze się z nim zapoznaj.

Heh, no dobrze. Dzięki , spróbuję ograniczyć zapytania do minimum, ale gdzie jest granica umniejszania ilości zapytań a ograniczania możliwości rozgrywki? (kwestia filozoficzna, nie szukam na to odpowiedzi ). Z LIMIT'em SQL jestem dość dobrze zapoznany - na tyle, że czasem nieświadomie go wpisuję do każdego zapytania, a później dziwię się co jest nie tak (odruchowo). Muszę tylko spędzić trochę czasu na złączeniach tabel.. ale mniejsza z tym .

Mam jednak teraz pytanie, nie powiązane już z tym tematem, lecz wciąż mnie nurtujące. Nie chcę Wam zaśmiecać forum niepotrzebnymi tematami, więc zapytam tutaj, choć z pewnością to nie ta kategoria. Chciałbym wykonać coś takiego, aby przy wpisywaniu tekstu do elementu textarea różnił się on kolorem w zależności pomiędzy jakimi znakami został umieszczony. Przedstawię to schematycznie:

Tekst tekst, tekst tekst tekst *Tekst tekst. Tekst tekst, tekst* tekst tekst.
// tekst tekst tekst... //

Szukam rozwiązania, które umożliwi zmianę koloru w czasie rzeczywistym, tak by tekst normalny był biały, tekst pomiędzy gwiazdkami był pomarańczowy, a pomiędzy ukośnikami był niebieski - a co najważniejsze zdatny do wysłania przez formularz, czyli umieszczony w elemencie textarea.. Z mojego punktu widzenia jest to niemożliwe, ale być może istnieje jakieś rozwiązanie?
Myślałem nad zastąpieniem elementu textarea warstwą div, która przyjmowała by wartości wpisywane z klawiatury za pomocą eventów w javascripcie - ale to rozwiązanie nie wydaje mi się dość stabilne, gdy przyjdzie wysłać formularz..
Istnieje jakaś metoda by w elemencie textarea umieścić tekst różniący się kolorem?

Istnieje jakaś metoda by w elemencie textarea umieścić tekst różniący się kolorem?

Nie znam takowej ale możesz rozwiązać to dwojako. Za pomocą JS a w wypadku problemów daj możliwość przełączenia się do zwykłego formularza.
Co do samego skryptu to nie ograniczaj się z zapytaniami gdzie się tylko da. Zaplanuj co ma robić Twój skrypt na kartce. Ja to nazywam specyfikacją projektu. Jeżeli jest to coś większego można pokusić się o diagramy użycia, klas itp itd etc. Ogólnie UML.
Jak już wszystko będzie zaplanowane, wtedy zastanawiaj się jak dany problem który sobie postawiłeś zrealizować bez stosowania dużej ilości zapytań oraz pobierania zbędnych danych z bazy.