forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)
-   PHP / MySQL (http://forum.boolean.name/forumdisplay.php?f=135)
-   -   Впросы новичка (http://forum.boolean.name/showthread.php?t=13517)

psih1 18.10.2010 08:26

Впросы новичка
 
Как лучше писать примитивный чат чтоб сообшения в txt или mysql сохранялись?

moka 19.10.2010 20:14

Ответ: Впросы новичка
 
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, который зависит от длины содержимого (колличества значков).

psih1 20.10.2010 17:47

Ответ: Впросы новичка
 
Спасибо.А как лучше сохранять координаты игрока в бд?

moka 20.10.2010 18:23

Ответ: Впросы новичка
 
Ну если они не обновляются чаще чем раз в несколько секунд, тогда просто два инта.
Зависит от вообще того что ты делаешь.
Если это броузерка, то тут нужно внедрять локации, и фильтровать по ним.
К примеру есть локация, которая имеет поле делёное на ячейки 256x256.
То значит у пользователя будут несколько столбцов, один указывающий ID локации, и это будет первый параметр по которому будет фильтрация для получения позиции. Короче говоря, получаешь координаты игроков только с твоей локации. (естественно проверка на online/offline пользователя).
Далее два столбца: pos_x и pos_y простой инт, длиной в 3 знака.
И при активности персонажа, отправляешь запрос на позицию, далее у другого игрока, должно происходить определённое событие для запроса позиций игроков, опять же, не чаще чем раз в несколько секунд.
Угу, таков броузерный мир, чтобы сервер не упал от перенагрузки, постоянных запросов и манипуляции данными.
Если пишешь такие вещи, очень важно правильно состовлять таблицы (например столбец с ID локацией, желательно индексовать, т.к. он будет очень часто использоваться как один из главных фильтров), далее в запросах, почаще используй Join и не получай все ячейки, а только то что тебе нужно.
Если используешь Ajax (для перемещения, желательно, но это уже немало работы с java-script, и тут нужно разрабатывать целую платформу), в общем если используешь Ajax, то запросы желательно пакуй, делай их короткими и ясными, удобен будет JSON для хорошей презентации данных.
В общем удачки ;)

Лучше поменьше вопросов, и побольше эксперементов делай, старайся сам найти решение, это тебе опыт даст, так и развиваться быстрее, чем просто задовать вопрос и получая ответ выполнять - опыта совсем чучуть, а без него потом никуда..

Nex 02.11.2010 07:54

Ответ: Впросы новичка
 
Есть ли какие-нибудь сайты где можно почитать про "вставку" php в html и работу с MySQL?

moka 02.11.2010 13:56

Ответ: Впросы новичка
 
Ссылка

Crayzi 10.01.2012 13:30

Ответ: Впросы новичка
 
Вопрос по MySQL: Допустим я имею базу Test, в ней есть таблица Accounts, в ней строка GUID содержащая уникальный порядковый номер игрока, как мне правильно оформить запрос чтобы база мне вернула самый большой GUID?

Randomize 10.01.2012 14:04

Ответ: Впросы новичка
 
Цитата:

Сообщение от Crayzi (Сообщение 216449)
Вопрос по MySQL: Допустим я имею базу Test, в ней есть таблица Accounts, в ней строка GUID содержащая уникальный порядковый номер игрока, как мне правильно оформить запрос чтобы база мне вернула самый большой GUID?

Код:

SELECT * FROM Accounts ORDER BY GUID DESC LIMIT 1
ORDER BY - сортировка по
DESC - обратная сортировка
LIMIT 1 - говорит что нам нужен 1 результат

Aikon 11.01.2012 00:48

Ответ: Впросы новичка
 
Как вариант
SELECT MAX(GUID) FROM Accounts
(надо сравнить какой отбегает быстрее; зависит от наличия и подхватывания индекса по GUID)

GUID - это обычно строка вида 6F9619FF-8B86-D011-B42D-00CF4FC964FF
делать ее идентификатором игрока наверно не очень желательно, поскольку поиск будет более тормознутый, нежели при использовании обычного number(10) для идентификации серверов.
GUID нужен, если планируется разворачивать приложение на нескольких серверах независимо, а потом объединять данные с них.

Crayzi 11.01.2012 16:17

Ответ: Впросы новичка
 
Цитата:

Сообщение от Aikon (Сообщение 216506)
Как вариант
SELECT MAX(GUID) FROM Accounts
(надо сравнить какой отбегает быстрее; зависит от наличия и подхватывания индекса по GUID)

GUID - это обычно строка вида 6F9619FF-8B86-D011-B42D-00CF4FC964FF
делать ее идентификатором игрока наверно не очень желательно, поскольку поиск будет более тормознутый, нежели при использовании обычного number(10) для идентификации серверов.
GUID нужен, если планируется разворачивать приложение на нескольких серверах независимо, а потом объединять данные с них.

Ну я как-бы делаю ММОРПГ на блитце, так что не думаю что мне понадобятся такие глобальные подходы прямо таки сразу)))
+ не совсем понял что ты имел ввиду(6F9619FF-8B86-D011-B42D-00CF4FC964FF и number(10));
я собираюсь использовать базу только для загрузке данных об игроке входящем в игру(вощел игрок в игру, загрузился его инвентарь, параметры и т. д., вышел - сэйв в базу и килл с ОЗУ), все остальное покачто будет в ОЗУ сервера, т. к. почти все данные какие будут в озу, будут постоянно менятся, регенерация энергии в щитах и генераторах, орудиях и т. п. :-D, а остальное будет динамическим и не особо требующим сохранения.
П.с. Но от советов не откажусь.

Кстати о птичках, насколько высока скорость ответа базы на простые запросы, и есть ли смысл работать с ними "почти так-же" как с оперативкой(всмысле не совсем оперативкой, а заставить обрабатывать некоторые действия вместо сервака)? Допустим, надо ответить игроку, сколько сейчас у него НР, запрос в базу -> ответ, надо обновить данные об энергии в щитах запрос в базу на прирост энергии(всмысле команда типа UPDATE добавить в ст1 (взять данные из ст2) если в ст1 число меньше ст3...). Или же это тормозно при больших объемах данных и проще все проссчитывать на сервере?

Aikon 11.01.2012 21:38

Ответ: Впросы новичка
 
Цитата:

не совсем понял что ты имел ввиду(6F9619FF-8B86-D011-B42D-00CF4FC964FF и number(10));
Ты спрашивал про GUID, что расшифровывается как глобальный идентификатор - http://ru.wikipedia.org/wiki/GUID
Механизм его генерации, практически гарантирует, что он будет всегда уникален. Для маленькой ММОРПГ для идентификации героя, т.е. его ID, использовать GUID не стоит, а вот number(10), что означает числовое поле в 10 разрядов с возможностью хранить числа от 1 до 999999999 в MySQL, вполне подойдет.

Скорость ответа у MySQL на уровне (запрос к таблице по идентификатору строки быстрый, но если для каждого игрока будет дергаться 200 запросов к разным таблицам, то любой сервер околеет), если что, то можно будет кэшировать запросы, чтобы в базу не лазить. Проводить расчеты на клиенте - это потенциальная дырка для читаков.
Т.е. тут скорее альтернатива: обзавестись мощным сервером (наличие $$$) или бороться с читерами.

P.S. С MySQL знаком мало, ММОРПГ не писал, так что возможно, что более опытные товарищи радикально с моим мнением не согласятся.

Crayzi 12.01.2012 14:28

Ответ: Впросы новичка
 
GUID в моем исполнении подразумевает ничто иное как порядковый номер игрока/предмета/модуля... Я думаю мне хватит 10-ти значного числа надолго)))

Помоги еще с 1 проблеммой:
Есть таблица Account, в ней строка "Login",
выполняю запрос в базу
Код:

Select Login FROM Account WHERE Login = Crayzi;
и такой пробовал
Код:

Select Login FROM Account WHERE (Login = Crayzi);
а в ответ 0, данным запросом я хотел проверять, есть-ли игрок с подобным именем в базе или нет...(игрок там есть :))
Однако
Код:

Select Login FROM Account WHERE GUID = 3;
Выдает правильный результат, а это означает что поиск по тексту надо производить както по другому...

...погуглил, нашел пару примеров, сделал как там но ничего не вышло, возможно надо какието параметры менять в самой базе?

moka 12.01.2012 14:31

Ответ: Впросы новичка
 
SELECT Login FROM Account WHERE Login = 'Crayzi'

Не называй простой ID, GUID'ом, это не верно. Тебе же объяснили что такое GUID, ты его не используешь, зачем тогда так называть колонку?

Crayzi 12.01.2012 14:51

Ответ: Впросы новичка
 
Цитата:

Сообщение от MoKa (Сообщение 216623)
SELECT Login FROM Account WHERE Login = 'Crayzi'

Не называй простой ID, GUID'ом, это не верно. Тебе же объяснили что такое GUID, ты его не используешь, зачем тогда так называть колонку?

Лан небуду, если честно, щас задумался и понял что чуток перемудрил, у меня для игрока и ИД есть, и ГУИД)))
Удивил, интересно почему Select работает не так-же как SELECT?

Aikon 12.01.2012 15:49

Ответ: Впросы новичка
 
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, время: 14:00.

vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot