Помогите Добавляется игрок в БД, даже если он уже есть в таблице!

[AlbertV]

Привет тому, кто читаем мою тему!

Столкнулся с одной проблемкой... Хочу, чтобы игрока добавляло в бд Mysql, если он зашел первый раз.
Добавляет, но он все равно добавляет игрока в бд, даже если он заходит на сервер не первый раз.

Прошу помочь!

 

[imDaniX]

Является ли в таблице столбец NAME ключом?

 

[AlbertV]

Является ли в таблице столбец NAME ключом?

нет

 

[imDaniX]

нет

Сделай его таковым х)

 

[AlbertV]

Сделай его таковым х)

Ок, попробую

 

[AlbertV]

Сделай его таковым х)

не помогло

 

[AlbertV]

 

[alexandrage]

И такое делается примерно так. "INSERT INTO users (user,time) VALUES (?,?) ON DUPLICATE KEY UPDATE time = ?;". колонка юзера должна быть единственным ключем.

 

[Reality_SC]

Yep

 

[Bars]

И такое делается примерно так. "INSERT INTO users (user,time) VALUES (?,?) ON DUPLICATE KEY UPDATE time = ?;". колонка юзера должна быть единственным ключем.

Я думал я вы*бнусь своими знаниями, а тут уже смотрю за меня этот вариант написали (ON DUPLICATE KEY UPDATE) 🙂

А так, ТС, у тебя жестко все написано.

1. Функция exists() благодаря предложенному варианту выше не нужна.
2. Нет проверки игрока на .hasPlayedBefore() - что и возвращает boolean того, был ли игрок раньше на сервере. Без этой проверки ты выполняешь лишний запрос на поиск того же игрока в БД. И этот поиск игрока в БД с вариантом выше
   

   И такое делается примерно так. "INSERT INTO users (user,time) VALUES (?,?) ON DUPLICATE KEY UPDATE time = ?;". колонка юзера должна быть единственным ключем.

   не нужен получается больше вообще. Зачем тебе проверять есть ли игрок в БД, чтобы его добавить, когда MySQL всё сама за тебя проверит? Короче если будешь использовать все как есть сейчас, добавляй проверку player.hasPlayedBefore(). А если будешь использовать "ON DUPLICATE KEY ...", то можно и не делать
3. Куча разделенных запросов, когда их надо максимально объединять между собой. Один запрос на одну функцию. Так нельзя, это один из самых базовых принципов (простейших просто, которые надо обязательно знать) оптимизации при работе с БД

 

[alexandrage]

Я думал я вы*бнусь своими знаниями, а тут уже смотрю за меня этот вариант написали (ON DUPLICATE KEY UPDATE) 🙂

А так, ТС, у тебя жестко все написано.

1. Функция exists() благодаря предложенному варианту выше не нужна.
2. Нет проверки игрока на .hasPlayedBefore() - что и возвращает boolean того, был ли игрок раньше на сервере. Без этой проверки ты выполняешь лишний запрос на поиск того же игрока в БД. И этот поиск игрока в БД с вариантом выше
   
   не нужен получается больше вообще. Зачем тебе проверять есть ли игрок в БД, чтобы его добавить, когда MySQL всё сама за тебя проверит? Короче если будешь использовать все как есть сейчас, добавляй проверку player.hasPlayedBefore(). А если будешь использовать "ON DUPLICATE KEY ...", то можно и не делать
3. Куча разделенных запросов, когда их надо максимально объединять между собой. Один запрос на одну функцию. Так нельзя, это один из самых базовых принципов (простейших просто, которые надо обязательно знать) оптимизации при работе с БД

Это просто был один из примеров юза. И hasPlayedBefore соснет после вайпа папки с игроками.

 

[Bars]

И hasPlayedBefore соснет после вайпа папки с игроками

Знаю. Просто я не вижу смысла ее вайпать. Но если скомбинировать два этих способа, то будет вообще изящно: если папка с игроками будет удалена, просто сделается запрос (выше). А если игрок есть - запрос сэкономится