Для того что бы заметно снять нагрузку в боях можно вместо
использовать запрос по следующим ячейкам
+возможно еще несколько ячеек в зависимости от вашей версии боев. лично мне этих хватает с головой.
и еще один совет - не поленитесь сделать в таблице person ячейку hp_max которая будет отвечать за максимальное количество жизни у игрока. тоже самое касается и манны и усталости.
это позволит избавиться от запросов по SUM (hp) с таблицы objects. если вам не критичен вывод статов в виде Сила 4 (3+1) то можно при одевании вещи добавлять значение от шмотки сразу к стату. Если же это необходимо - создаем в таблица person (либо же в дополнительной таблице) ячейки с названиями статов и при одевании и снятии вещей оперируем с этими значениями. Выборка 1го ряда с дополнительной таблицы, либо же 6 (статов) + 3 (макс значения) = 9 ячеек с таблицы person куда более быстрее чем просчет суммы добавляемых бонусов от одетых вещей. С модификаторами делаем собственно говоря тоже самое.
*********************************************************
что касается текущих и завершенных боев... возможно кто-то в меня кинет камнем, хотя зря.
имхо самое оптимально решение для реализации подобных разделов заявки наиболее лучше осуществлять с помощью 2х таблиц. одна для текущих, вторая для завершенных. таблицы должны иметь ячейки: id, battle_id, time, side_left, side_right, side_win (для завершенных)
А вот теперь в чем загвоздка. В в ячейки side_left и side_right я советую заносить уже отформатированные данные. причем не javascript версию, а именно html код.
возможные альтернативы, которые я проверял на работоспособность но отказался:
1. заносим ID пользователей в виде ID1|ID2|ID..|IDn. далее скриптовой частью PHP разделяем |, получаем ID юзеров, выбираем данные с таблицы person, выводим юзеров. Сей способ ужасен тем что при 20-ти боях на страницу при условии 2 человека в бою сделает 40 запросов к базе.
2. заносим псевдо массивы вида {userID|userName|userLevel|userRank|userTribe|userSex}{userID|userName|userLevel
|userRank|userTribe|userSex} далее при выводе разбираем полученные данные скриптовой частью и делаем вывод. Вроде бы не плохо, но при больших боях сервер будет ужасающе тупить от такой обработки. Ему нужно будет порезать эти данные на массив юзеров, разбить каждый из массивов на подмассивы и уже потом выводить данные.
3. заносим данные в виде <script>show_player(userID,userName,userLevel,userRank,userTribe,userSex);</SCRIPT> с учетом форматирования под яваскрипт, тоесть расставляя везде нужные кавычки и т.п. Данный способ похож на мой, но он имеет свои недостатки. Я вообще являюсь антипоклонником javascript, но здесь дело даже не в этом. Он сам по себе хорош, но нужно знать где стоит его использовать а где нет. В данном случае мы имеем 2 недостатка. Первый - при больших боях (например у вас хороший онлайн, и нужно вывести 20 хаотических боев в которых участвует около 50 человек). js обрабатывается на стороне клиента, и он попросту будет подвешивать браузер пока не обработает всю информацию, в отличии от php который будет выводить данные постепенно никому не вредя. Недостаток второй - show_player работает с выводом через document.write, а это значит что вы никогда в жизни его не выведите на страницу с помощью AJAX. В результате вывода аяксом у вас обрежется все что было, но зато будет белый лист и заявки. Это меня абсолютно не устраивает. Для того что бы от этого избавится нужно на каждый вывод игрока генерировать свой <span>, присваивать ему уникальный ID, и модифицировать вывод игрока с document.write на innerHTML. а это ой как не интересно.
by UnDeaD
Код:
SELECT * FROM person
использовать запрос по следующим ячейкам
Код:
DEFINE('userCell_ID', 'id' );
DEFINE('userCell_Name', 'user' );
DEFINE('userCell_Pass', 'pass' );
DEFINE('userCell_Battle', 'battle' );
DEFINE('userCell_HPnow', 'hp_now' );
DEFINE('userCell_MPnow', 'energy_now' );
DEFINE('userCell_HPmax', 'hp_max' );
DEFINE('userCell_MPmax', 'energy_max' );
DEFINE('userCell_Level', 'level' );
DEFINE('userCell_Rank', 'rank' );
DEFINE('userCell_Tribe', 'tribe' );
DEFINE('userCell_Sex', 'sex' );
DEFINE('userCell_Room', 'room' );
DEFINE('userCell_Credits', 'credits' );
DEFINE('userCell_Side', 'side' );
DEFINE('userCell_Blocked', 'bloked' );
DEFINE('userCell_strength', 'strength' );
DEFINE('userCell_dex', 'dex' );
DEFINE('userCell_agility', 'agility' );
DEFINE('userCell_vitality', 'vitality' );
DEFINE('userCell_power', 'power' );
DEFINE('userCell_razum', 'razum' );
DEFINE('userCell_Obraz', 'obraz' );
DEFINE('userCell_Up', 'up' );
DEFINE('userCell_Exp', 'exp' );
DEFINE('userCell_Invisible', 'invisible' );
+возможно еще несколько ячеек в зависимости от вашей версии боев. лично мне этих хватает с головой.
и еще один совет - не поленитесь сделать в таблице person ячейку hp_max которая будет отвечать за максимальное количество жизни у игрока. тоже самое касается и манны и усталости.
это позволит избавиться от запросов по SUM (hp) с таблицы objects. если вам не критичен вывод статов в виде Сила 4 (3+1) то можно при одевании вещи добавлять значение от шмотки сразу к стату. Если же это необходимо - создаем в таблица person (либо же в дополнительной таблице) ячейки с названиями статов и при одевании и снятии вещей оперируем с этими значениями. Выборка 1го ряда с дополнительной таблицы, либо же 6 (статов) + 3 (макс значения) = 9 ячеек с таблицы person куда более быстрее чем просчет суммы добавляемых бонусов от одетых вещей. С модификаторами делаем собственно говоря тоже самое.
*********************************************************
что касается текущих и завершенных боев... возможно кто-то в меня кинет камнем, хотя зря.
имхо самое оптимально решение для реализации подобных разделов заявки наиболее лучше осуществлять с помощью 2х таблиц. одна для текущих, вторая для завершенных. таблицы должны иметь ячейки: id, battle_id, time, side_left, side_right, side_win (для завершенных)
А вот теперь в чем загвоздка. В в ячейки side_left и side_right я советую заносить уже отформатированные данные. причем не javascript версию, а именно html код.
возможные альтернативы, которые я проверял на работоспособность но отказался:
1. заносим ID пользователей в виде ID1|ID2|ID..|IDn. далее скриптовой частью PHP разделяем |, получаем ID юзеров, выбираем данные с таблицы person, выводим юзеров. Сей способ ужасен тем что при 20-ти боях на страницу при условии 2 человека в бою сделает 40 запросов к базе.
2. заносим псевдо массивы вида {userID|userName|userLevel|userRank|userTribe|userSex}{userID|userName|userLevel
|userRank|userTribe|userSex} далее при выводе разбираем полученные данные скриптовой частью и делаем вывод. Вроде бы не плохо, но при больших боях сервер будет ужасающе тупить от такой обработки. Ему нужно будет порезать эти данные на массив юзеров, разбить каждый из массивов на подмассивы и уже потом выводить данные.
3. заносим данные в виде <script>show_player(userID,userName,userLevel,userRank,userTribe,userSex);</SCRIPT> с учетом форматирования под яваскрипт, тоесть расставляя везде нужные кавычки и т.п. Данный способ похож на мой, но он имеет свои недостатки. Я вообще являюсь антипоклонником javascript, но здесь дело даже не в этом. Он сам по себе хорош, но нужно знать где стоит его использовать а где нет. В данном случае мы имеем 2 недостатка. Первый - при больших боях (например у вас хороший онлайн, и нужно вывести 20 хаотических боев в которых участвует около 50 человек). js обрабатывается на стороне клиента, и он попросту будет подвешивать браузер пока не обработает всю информацию, в отличии от php который будет выводить данные постепенно никому не вредя. Недостаток второй - show_player работает с выводом через document.write, а это значит что вы никогда в жизни его не выведите на страницу с помощью AJAX. В результате вывода аяксом у вас обрежется все что было, но зато будет белый лист и заявки. Это меня абсолютно не устраивает. Для того что бы от этого избавится нужно на каждый вывод игрока генерировать свой <span>, присваивать ему уникальный ID, и модифицировать вывод игрока с document.write на innerHTML. а это ой как не интересно.
by UnDeaD