Реклама Google — средство выживания форумов :)
Внутри игры используются уникальные идентификаторы, присваиваемые каждому объекту. Внутри сервера эти идентификаторы соотносятся соответственно с типом объекта и его параметрами. Так что действительно хранить эти ID в базе совсем не обязательно. Более сервер никак к идентификаторам не привязан. т.е. если тебе нужен аккаунт, делаешь выборку по login + hash(pass), при этом получаешь внутрибазовый id пользователя, по которому дольше идет поиск связанных записей.NetImperia:Как используются идентификаторы пользователей. Это что что-бы получить пользователя, идет обращение к ID в базе. А затем по этому ID ищится ник и работа по никам производится?
Если так то это вообще берд полный. Как я понимаю в идеале нужно получать ID, login, ID клана, Имя клана и ник персонажа тогда когда игрок входит на сервер. И всегда его помнить пока он не выйдет.
Тогда не нужно будет думать что использовать для доступа. Можно использовать как ник так и ID. Если конечно его нужно тут использовать. А не читать из базы его каждый раз.
Насколько я знаю, индексы строятся на основе хешей значений. Соответственно при поиске из значения получается его хеш и дальше идет уже поиск по числу. Но как только у нас строковая переменная оказывается неиндексированной, вот тут-то и идет зверское падение скорости (на больших таблицах)NetImperia:Как не крути, а по ID доступ в разы быстрее если по этому полю построен индекс. Так как тогда все это число помещается в индексе если конечно оно в разумных переделах.А если делать поиск по строкам. То тогда это медленее будет. Потому что тогда в индексе не будет отиндексировано все слово ,а только часть его. И поиск будет медлеенее.
Balancer:(напомню, имена у нас уникальные, скорость поиска по индексированной строке в mysql не ниже, чем поиск по индексированным числовым значениям).
Заблуждаешся. Медленее. На маленьких базах этого не будет заметно. Но когда записей много тогда это очень заметно.
NetImperia:Balancer:- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся
А как тогда обращаться к мобам или каким-то вещам в квестах?
Например какой-нить квест пойди найди то-то. И дотронься. Это так для примера.
Имелось ввиду переназначение ID. Это тоже надо будет делать, но во много раз реже, чем сейчас.NetImperia:Balancer:- не потребуется сжатие БД
В этом я сомневаюсь. Все равно придется. Например после удаления пользователя.
Полностью согласен.NetImperia:Balancer:- проще будет работать визуально с БД (скажем, сразу видишь, какому игроку принадлежит предмет)
Пользователи и админы вообще не должны лазать в базу что-бы произвести какие-то манипуляции. Все эти манипуляции должны делаться через интерфейсы в игре либо WEB интерфейсы.
awarm:Внутри игры используются уникальные идентификаторы, присваиваемые каждому объекту. Внутри сервера эти идентификаторы соотносятся соответственно с типом объекта и его параметрами. Так что действительно хранить эти ID в базе совсем не обязательно. Более сервер никак к идентификаторам не привязан. т.е. если тебе нужен аккаунт, делаешь выборку по login + hash(pass), при этом получаешь внутрибазовый id пользователя, по которому дольше идет поиск связанных записей.
awarm:Насколько я знаю, индексы строятся на основе хешей значений. Соответственно при поиске из значения получается его хеш и дальше идет уже поиск по числу. Но как только у нас строковая переменная оказывается неиндексированной, вот тут-то и идет зверское падение скорости (на больших таблицах)
zabbix:ок, а если сделать пул свободных идентификаторов?
Ну вот и славненько! Над новой схемой базы уже начал работать? если да, то положи в root/L2J Balancer/sql... глянуть хоцца.Balancer:>Ну если внутриигровые генерить по порядку, а в базе использовать нормальные свои, тогда можно
Да, я так и предлагаю
Ну... тебе виднее а переиндексация будет "insert into items_tmp (...) select ... from items" ? если да (типа не надо будет делать изменения в других таблицах изза смены ID-шника) то это ваше рулить будет. можно по дефоулту при старте сервера включить - по времени займет пару секунд...Balancer:>А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что
это не вариант...
Чем не вариант? Даже обычного INT'а хватит на несколько лет, а в случае чего, переиндексация займёт считанные секунды и без сбоев в общей БД. Считать просто в новую таблицу и всё
Выборка - да, быстро. а вот инсерт мульти-индексного поля может начать тормозить (в одном проекте есть рабочая табличка где есть 6 текстовых полей, одно с уникальным индексом, остальные просто проиндексированы,один биг инт автоинкремент примари кей, 4 дате, 1 датетайм ну и несколько тиниинтов - дык на 434856 записях инсерт туда делается почти пол секунды) хотя если будет всего один текстовый индекс может все будет пучком...Balancer:>Ты считаешь, что текстовые поля будут лучше???
С точки зрения скорости выборки в mysql - пофиг. И все принадлежности, типа
id игроков или кланов безусловно лучше делать текстовыми, именными. Очень
упростится ручная работа с БД
zabbix:>Пользователи и админы вообще не должны лазать в базу что-бы произвести какие-то манипуляции. Все эти манипуляции должны делаться через интерфейсы в игре либо WEB интерфейсы.
Прекрасно, но ты такой интерфейс сделаешь? Тогда вопрос отпадёт. Пока же все задачи приходится решать через phpMyAdmin или из консоли
Balancer:>Пользователи и админы вообще не должны лазать в базу что-бы произвести какие-то манипуляции. Все эти манипуляции должны делаться через интерфейсы в игре либо WEB интерфейсы.
Прекрасно, но ты такой интерфейс сделаешь? Тогда вопрос отпадёт. Пока же все задачи приходится решать через phpMyAdmin или из консоли