Впросы новичка
Как лучше писать примитивный чат чтоб сообшения в txt или mysql сохранялись?
|
Ответ: Впросы новичка
MySQL конечно.
Больше информации храниться будет, а также меньше нагрузки на сервер, т.к. запросы будешь осуществлять только на те сообщения которых нет, эдакий последний индекс сообщения (в виде индексации может быть дата создания записи в базе данных (почти эквивалентна дате сообщения по времени сервера) ). Структура бд может быть проста, если есть поддержка пользователей, то хранить нужно и Primary Key пользователя. Простейшая таблица: id[int](primary key, auto incement) | user_id[int] | time[datetime] | message[varchar(255)] Если сообщения ограниченной длины (255 значков), то использую varchar, если пространство на сервере не имеет значения, используй тип данного text, но советую ограничивать длину text field'а всё равно, дабы избежать перегрузки, когда кто-то захочет постануть 20 раз подряд, 200 страниц из какой-нибудь книжечки :) Тип данных text также имеет динамичный размер, как и varchar, который зависит от длины содержимого (колличества значков). |
Ответ: Впросы новичка
Спасибо.А как лучше сохранять координаты игрока в бд?
|
Ответ: Впросы новичка
Ну если они не обновляются чаще чем раз в несколько секунд, тогда просто два инта.
Зависит от вообще того что ты делаешь. Если это броузерка, то тут нужно внедрять локации, и фильтровать по ним. К примеру есть локация, которая имеет поле делёное на ячейки 256x256. То значит у пользователя будут несколько столбцов, один указывающий ID локации, и это будет первый параметр по которому будет фильтрация для получения позиции. Короче говоря, получаешь координаты игроков только с твоей локации. (естественно проверка на online/offline пользователя). Далее два столбца: pos_x и pos_y простой инт, длиной в 3 знака. И при активности персонажа, отправляешь запрос на позицию, далее у другого игрока, должно происходить определённое событие для запроса позиций игроков, опять же, не чаще чем раз в несколько секунд. Угу, таков броузерный мир, чтобы сервер не упал от перенагрузки, постоянных запросов и манипуляции данными. Если пишешь такие вещи, очень важно правильно состовлять таблицы (например столбец с ID локацией, желательно индексовать, т.к. он будет очень часто использоваться как один из главных фильтров), далее в запросах, почаще используй Join и не получай все ячейки, а только то что тебе нужно. Если используешь Ajax (для перемещения, желательно, но это уже немало работы с java-script, и тут нужно разрабатывать целую платформу), в общем если используешь Ajax, то запросы желательно пакуй, делай их короткими и ясными, удобен будет JSON для хорошей презентации данных. В общем удачки ;) Лучше поменьше вопросов, и побольше эксперементов делай, старайся сам найти решение, это тебе опыт даст, так и развиваться быстрее, чем просто задовать вопрос и получая ответ выполнять - опыта совсем чучуть, а без него потом никуда.. |
Ответ: Впросы новичка
Есть ли какие-нибудь сайты где можно почитать про "вставку" php в html и работу с MySQL?
|
Ответ: Впросы новичка
|
Ответ: Впросы новичка
Вопрос по MySQL: Допустим я имею базу Test, в ней есть таблица Accounts, в ней строка GUID содержащая уникальный порядковый номер игрока, как мне правильно оформить запрос чтобы база мне вернула самый большой GUID?
|
Ответ: Впросы новичка
Цитата:
Код:
SELECT * FROM Accounts ORDER BY GUID DESC LIMIT 1 DESC - обратная сортировка LIMIT 1 - говорит что нам нужен 1 результат |
Ответ: Впросы новичка
Как вариант
SELECT MAX(GUID) FROM Accounts (надо сравнить какой отбегает быстрее; зависит от наличия и подхватывания индекса по GUID) GUID - это обычно строка вида 6F9619FF-8B86-D011-B42D-00CF4FC964FF делать ее идентификатором игрока наверно не очень желательно, поскольку поиск будет более тормознутый, нежели при использовании обычного number(10) для идентификации серверов. GUID нужен, если планируется разворачивать приложение на нескольких серверах независимо, а потом объединять данные с них. |
Ответ: Впросы новичка
Кстати о птичках, насколько высока скорость ответа базы на простые запросы, и есть ли смысл работать с ними "почти так-же" как с оперативкой(всмысле не совсем оперативкой, а заставить обрабатывать некоторые действия вместо сервака)? Допустим, надо ответить игроку, сколько сейчас у него НР, запрос в базу -> ответ, надо обновить данные об энергии в щитах запрос в базу на прирост энергии(всмысле команда типа UPDATE добавить в ст1 (взять данные из ст2) если в ст1 число меньше ст3...). Или же это тормозно при больших объемах данных и проще все проссчитывать на сервере? |
Ответ: Впросы новичка
Цитата:
Механизм его генерации, практически гарантирует, что он будет всегда уникален. Для маленькой ММОРПГ для идентификации героя, т.е. его ID, использовать GUID не стоит, а вот number(10), что означает числовое поле в 10 разрядов с возможностью хранить числа от 1 до 999999999 в MySQL, вполне подойдет. Скорость ответа у MySQL на уровне (запрос к таблице по идентификатору строки быстрый, но если для каждого игрока будет дергаться 200 запросов к разным таблицам, то любой сервер околеет), если что, то можно будет кэшировать запросы, чтобы в базу не лазить. Проводить расчеты на клиенте - это потенциальная дырка для читаков. Т.е. тут скорее альтернатива: обзавестись мощным сервером (наличие $$$) или бороться с читерами. P.S. С MySQL знаком мало, ММОРПГ не писал, так что возможно, что более опытные товарищи радикально с моим мнением не согласятся. |
Ответ: Впросы новичка
Помоги еще с 1 проблеммой: Есть таблица Account, в ней строка "Login", выполняю запрос в базу Код:
Select Login FROM Account WHERE Login = Crayzi; Код:
Select Login FROM Account WHERE (Login = Crayzi); Однако Код:
Select Login FROM Account WHERE GUID = 3; ...погуглил, нашел пару примеров, сделал как там но ничего не вышло, возможно надо какието параметры менять в самой базе? |
Ответ: Впросы новичка
SELECT Login FROM Account WHERE Login = 'Crayzi'
Не называй простой ID, GUID'ом, это не верно. Тебе же объяснили что такое GUID, ты его не используешь, зачем тогда так называть колонку? |
Ответ: Впросы новичка
Цитата:
Удивил, интересно почему Select работает не так-же как SELECT? |
Ответ: Впросы новичка
Crayzi, думаю тебе стоит почитать простенькое пособие по MySQL и базам данных вообще, напр. Томсон, Веллинг - Разработка Web-приложений на РНР и MySQL. Это снимет большую часть проблем и вопросов в дальнейшем. Разборка методом - получилось-не получилось приводит к не системным знаниям (по моему опыту).
Теперь по твоим проблемам 1. Команды, столбцов и таблиц MySQL нечувствительны к регистру, т.е. запросы Select Login... SELECT login... select loGin... Идентичны. 2. Для работы со строками надо знать, что строковые константы обрамлять в кавычки. В MySQL есть три типа кавычек - ", ', ` Надо понимать в чем их разница. А так же хотя бы примерно представлять, что такое sql-injection и потому стараться избегать выполнять запросы вида select ... from Accounts where login = СтрокаОтПользователя в виду их опасности. Лично я избегаю называть столбцы таблицы id. Вместо это использую <имятаблицы>_id, т.е. если таблица Accounts, то первый столбец будет account_id. Это помогает избежать конфликтов имен при запросах с разных таблиц, а так же то, что id зарезервированное слово и иногда приходится его в ` оборачивать, чтобы заработало. |
Часовой пояс GMT +4, время: 09:28. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot