Был ли у кого-то опыт с использованием хранимых процедур для игровых серверов? Если да - в каких случаях?
Вид для печати
Был ли у кого-то опыт с использованием хранимых процедур для игровых серверов? Если да - в каких случаях?
Когда это действительно нужно, когда нужно записать куда-то промежуточные данные для запросов. Банальный пример (хотя должен работать DELETE CASCADE). Мы удаляем аккаунт игрока: нужно удалить все данные и в других таблицах, кроме users. Если это делать через запросы получается каша из нескольких запросов, когда можно вызывать хранимую процедуру и это будет куда красивее, хотя повторюсь, что на другие таблицы должен работать DELETE CASCADE, если мы удаляем данные в users, то все остальные данные игрока должны автоматом удалится, но во всех модах, которые в паблике нет связей с таблицами через foreign key
Да, на счёт этого всё настроено. Спасибо
Ну автоматическое изменение/удаление данных в таблицах лучше делать через внешние ключи (связи), а не через процедуры. Ни к чему самостоятельно изобретать велосипед. И то, даже тут нужно работать с внешними ключами умеючи (как, собственно, и со всем в MySQL).
А в SAMP, в целом, MySQL используют на крайне примитивном уровне. Для большинства скриптеров MySQL - это какая-то волшебная штука, которая, вроде как, увеличивает скорость работы сервера.
1) Длинные запросы (не так много смысла в этом, но как вариант).
2) Часто повторяющиеся запросы.
3) Написание целых скриптов, которые бы выполнялись на стороне MySQL-сервера (например, вот это извращение вполне можно реализовать в виде процедуры, переложив всю возню с циклом на плечи MySQL).
и т.п.
Ну и ещё тогда советую обратить своё внимание, как минимум, на эвенты. Тоже может быть полезно для уменьшения лишних взаимодействий между игровым сервером и БД.
Есть инвентарь, в котором могут быть комбинирующие предметы (то есть добавляться будет в один уже существующий слот).
Вопрос про добавление этих самых комбинирующих предметов. Когда будем добавлять сразу больше 1 комбинирующего предмета, то придётся циклом добавлять все эти предметы (а там и запросы в бд и т.п.).
Так вот как скажется такой выбор добавления на большом онлайне и стоит ли пересмотреть механизм добавления?
Не очень понятно о каких запросах идёт речь. Выдаёшь ты, например, 300 патронов к МР5, а в одном слоте у тебя может не больше 100 патрон храниться. Соответственно, у тебя будет всего 3 запроса в БД на обновление данных о содержимом слотов. А все проверки на содержимое слотов и т.п. будут происходить на стороне сервера.
Не могу понять как лучше составить индексы.
Есть столбцы type, account_id.
При загрузке я обращаюсь только к account_id.
При обновлении к type AND account_id.
Думал сделать составной (type_account_id), затем отдельно для type и account_id.
Как лучше будет сделать?
Если к type отдельно не обращаешься, то достаточно сделать составной индекс
account_id, type
Если же планируешь отдельно обращаться и к type, то тогда создай дополнительный индекс для этого поля (для поля account_id отдельный индекс создавать не нужно)
В случае с составными индексами MySQL позволяет обращаться только к отдельным индексам, если они идут в порядке объявления.
То бишь, если имеется составной индекс:
index_1, index_2, index_3, index_4
То ты можешь использовать при выборке:
index_1, index_2, index_3 //... index_1, index_2 //... index_1
И такие запросы будут обрабатываться так же, как если бы ты создал отдельные индексы для этих столбцов.
Но, например, вот так использовать составной индекс:
index_2, index_3, index_4 //... index_1, index_2, index_4 //... index_4
Уже не получится и в этом случае MySQL не будет использовать индексы при выборке данных.
Вообще в ситуациях, когда у тебя запрос, потенциально, будет работать с большим количеством данных, лучше заранее тестировать то, как БД будет обрабатывать твой получившийся запрос, ибо оптимизатор MySQL довольно прихотливый и очень легко простым запросом заставить БД, например, копировать содержимое всей таблицы, к которой ты обращаешься, во временную таблицу, из которой MySQL уже и будет делать выборку, грубо говоря. В общем, лучше почитать и о средствах диагностики, которые имеются в MySQL, и о том, каких вещей лучше избегать в запросах.
Есть инвентарь оружия на textdraw'ах. Как сделать так, чтобы при наводке на textdraw с моделью - появлялся другой textdraw с нужным мне текстом, а потом исчезал. На скрине обведён зелёным textdraw, который должен по задумке появляться при наводке курсором (не кликая на него)
:https://i.ibb.co/ZG6d7dD/4444444.jpg
Без клиентского скрипта вряд ли такое возможно. Со стороны сервера момент наведения на кликабельный текстдрав никак не отловить, а единственное, что как-то влияет на кликабельные текстдравы в момент наводки - цвет, который передаётся в SelectTextDraw.
Можно сделать более тёмный фон для каждой клетки и попытаться спрятать текстдрав с ценой за ним, дабы потом в SelectTextDraw передать цвет с достаточной прозрачностью, и тогда получится что-то подобное твоей задумке, но именно отображать новый текстдрав в момент наведения на какой-то из кликабельных текстдравов - нет, стандартными средствами этого сделать нельзя.