SA-MP Forums

Go Back   SA-MP Forums > Non-English > Languages > Русский/Russian

Reply
 
Thread Tools Display Modes
Old 23/02/2019, 04:21 PM   #11
Eims
Huge Clucker
 
Eims's Avatar
 
Join Date: May 2013
Location: Восточный Мордор
Posts: 474
Reputation: 19
Default Re: Вопрос по чтение и сравнению

Quote:
Originally Posted by Johhnyllll View Post
Есть ли разница по скорости поиска по ID и нику?
Особенно когда в БД около 10к аккаунтов?
Дополню ответ выше простым рассуждением:
Строка состоит из символов. Символ хранится в виде числа. Следовательно, когда ты сравниваешь строки, ты сравниваешь определённый набор чисел, количество которых зависит от длины строки.
Ну а когда ты просто сравниваешь 2 числа, ты сравниваешь только 2 числа
__________________
- How many IT Engineers does it take to fix a broken light bulb?
- None, the light bulb works fine in my office, I cannot replicate the issue.
Eims is offline   Reply With Quote
Old 23/02/2019, 05:04 PM   #12
Eims
Huge Clucker
 
Eims's Avatar
 
Join Date: May 2013
Location: Восточный Мордор
Posts: 474
Reputation: 19
Default Re: Вопрос по чтение и сравнению

Quote:
Originally Posted by KrYpToDeN View Post
Профиль:
ID (ауто инкремент, примари кей), почта, скилл, деньги и тд.

Аккаунты:
ID (ауто инкремент. Данный столбец по желанию), Ник, ПрофильID (форейнг кей с отсылкой на ID из профиля).
ID (ауто инкремент. Данный столбец по желанию), Ник, ПрофильID (форейнг кей с отсылкой на ID из профиля).
ID (ауто инкремент. Данный столбец по желанию), Ник, ПрофильID (форейнг кей с отсылкой на ID из профиля).


Я бы сделал так и только так.
1) Не за чем устраивать огород с кучей ключей в одной строке.
2) Удобство чтения.
3) В случае чего можно очень быстро чтот поправить, сделать удобно выборку и тд.
4) Неограниченное число персонажей на 1 аккаунт. Лимит ставишь в коде. В любое время можно изменить лимит 1 значением всего лишь.


А насчет быстроты выборки, есть LIMIT %d
Если не стоит задачи сделать неограниченное количество аккаунтов, то делать так - сомнительное решение.

Представим, что у нас есть таблица с миллионом аккаунтов и мы разрешим игрокам создать до 10 персонажей на один аккаунт.
Следовательно, у нас получаются такие результаты:
PHP Code:
Таблица аккаунтов 1.000.000 записей
Таблица персонажей 
10.000.000 записей 
В моём случае, чтоб найти всех персонажей игрока (факт их наличия), достаточно просто найти одну запись в таблице аккаунтов и из неё выгрузить нужные данные.
В твоём случае придётся делать запрос сначала в таблицу с миллионом записей, чтоб узнать ID аккаунта, а потом уже запрос в таблицу с 10-ю миллионами записей (мы будем это делать всякий раз, когда у игрока меньше 10 персонажей или если персонажи игрока находятся последними в списке и никакой LIMIT тут не исправит ситуацию). При этом, чтоб узнать, создал ли игрок вообще персонажей и если создал, то сколько их, нам придётся прошерстить все 10 миллионов записей. А данная информация будет нужна довольно часто (как минимум, когда игрок открывает список персонажей) и в моём случае мы всё так же работаем с одной строкой из таблицы аккаунтов, не трогая таблицу персонажей.


В итоге, как видно, твоя реализация имеет кучу неоправданных действий для таблицы лишь ради того, чтоб иметь возможность "на лету" увеличивать число персонажей для одного аккаунта (что вряд ли будет полезно). А с учётом того, что ID аккаунта в таблице персонажей - ни разу не уникальное значение, какая-то более-менее серьёзная выборка, которая заставит MySQL создавать временные таблицы для хранения промежуточных данных, может ещё сильнее замедлить запросы.

ИМХО, уж лучше нагородить 2/5/10/20 дополнительных столбцов под персонажей в таблице аккаунтов (или же создать третью таблицу под них, если вы настолько эстеты), но точно знать сколько персонажей создано, под каким номером строки они находятся и свести к минимуму обращение к "тяжёлой" таблице, чем иметь ненужную псевдо-гибкость и, при этом, заставлять MySQL всякий раз проверять кучу записей.
Тем более, что таблица с аккаунтами при таком раскладе и так будет хранить лишь самую общую инфу, по типу пароля, почты и всякий инфы для защиты аккаунта, следовательно, хранение каждого персонажа в отдельном столбце никак негативно не скажется на таблице даже с визуальной части.



UPD: Пройдусь более подробнее по пунктам

Quote:
Originally Posted by KrYpToDeN View Post
2) Удобство чтения.
3) В случае чего можно очень быстро чтот поправить, сделать удобно выборку и тд.
Как выше уже описал, удобство если и будет, то только для скриптера. Для MySQL же наоборот количество действий увеличится пропорционально. Крайне сомнительно в данном случае жертвовать быстродействием ради того, чтоб запросы стали на 10 символов короче, ибо висящая БД = висящий сервер (по крайней мере жалобы на лаги вы точно себе обеспечите от игроков).

Quote:
Originally Posted by KrYpToDeN View Post
В любое время можно изменить лимит 1 значением всего лишь.
В предложенном мной варианте так же можно оформить код так, чтоб увеличение лимита занимало лишь одно действие. Точнее, два: изменение константы в коде и создание нужного числа столбцов (хотя и создание/удаление столбцов можно спокойно автоматизировать при старте сервера. Правда, вряд ли все усилия будут оправданы, так как лимит если и будет изменяться, то пару раз за всю жизнь сервера и проще вручную вносить изменения в структуру базы, чем писать для этого кучу дополнительного кода, который будет 99% времени срабатывать в холостую). Так что сомнительный плюс.
__________________
- How many IT Engineers does it take to fix a broken light bulb?
- None, the light bulb works fine in my office, I cannot replicate the issue.
Eims is offline   Reply With Quote
Old 24/02/2019, 06:07 AM   #13
cm666
Huge Clucker
 
Join Date: Jul 2012
Posts: 467
Reputation: 8
Default Re: Вопрос по чтение и сравнению

Quote:
Originally Posted by Eims View Post
Таблица персонажей - 10.000.000 записей[/PHP]
В моём случае, чтоб найти всех персонажей игрока (факт их наличия), достаточно просто найти одну запись в таблице аккаунтов и из неё выгрузить нужные данные.
Тебе в любом случая придется прогонять таблицу с 10 лямами значений. Для быстроты выборки есть индексы. И MySQL явно рассчитан на работу с таким колвом записей
cm666 is offline   Reply With Quote
Old 24/02/2019, 11:55 AM   #14
Eims
Huge Clucker
 
Eims's Avatar
 
Join Date: May 2013
Location: Восточный Мордор
Posts: 474
Reputation: 19
Default Re: Вопрос по чтение и сравнению

Quote:
Originally Posted by cm666 View Post
Тебе в любом случая придется прогонять таблицу с 10 лямами значений. Для быстроты выборки есть индексы. И MySQL явно рассчитан на работу с таким колвом записей
В том и дело, что в моём случае мы будем заранее знать сколько строк нужно найти и под каким ID они находятся, чем мы сразу закроем ряд вопросов, которые требовали бы обращения к таблице с 10 миллионами записей + поиск будет проходить по уникальному индексу, что сведёт количество проверок для MySQL к минимуму (как минимум, на одну проверку меньше). Не говоря уже о ситуациях, когда нам изначально нужно работать с конкретным персонажем.
+ не будем забывать о том, что при выборке нельзя использовать больше одного индекса в условии, что может сильно подпортить кровь при составлении сложных запросов в случае, если накрутить бессмысленный индекс на поле с ID аккаунта. Можно, конечно, создавать составные индексы, но это лишь впустую раздует размер таблицы (напомню, что основной плюс всей этой затеи - отсутствие нужды создавать дополнительный столбец для хранения ID персонажа, что автору и не нужно, судя по тому, что он чётко указал количество персонажей).

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

UPD: тут ещё можно вспомнить, например, про кластерные индексы, что в моём случае так же ускорит работу с данными, но это уже лирика. Собственно, дальше нет смысла эту тему продолжать. Кто желает стрелять в собственную ногу, оправдывая это "гибкостью" (хотя как выше уже писал, в моём варианте так же можно добиться гибкости) - ваше право. Но отрицать то, что конкретизация положительно влияет на скорость работы с данными - глупо, хотя, опять же, это ваше право. Уточню лишь, что никто не утверждает, будто вариант, предложенный KrYpToDeN, станет каким-то смертельным и что его ни в коем случае нельзя использовать. Речь лишь о том, что нужно разумно использовать ресурсы и тратить их на решение конкретных задач, а не пытаться решить то, что и решать пока не требуется (да и вряд ли потребуется). И то, что предлагаете вы - неоправданная трата ресурсов (как в плане памяти, так и в плане скорости обработки запросов) на функционал, который не будет использоваться автором.

UPD2: Несомненно, если стоит задача написать систему с неограниченным числом персонажей, то вариант KrYpToDeN будет гораздо оптимальнее. Но такой задачи не стоит и у нас есть вполне вменяемое количество персонажей, которых гораздо проще хранить в таблице с аккаунтами, а не терзать всякий раз таблицу персонажей лишь затем, чтоб понять, создал ли игрок хоть одного персонажа или нет.
__________________
- How many IT Engineers does it take to fix a broken light bulb?
- None, the light bulb works fine in my office, I cannot replicate the issue.
Eims is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Чтение с файла и запись. Romz Русский/Russian 20 15/07/2013 11:45 AM
Чтение с файла Romz Русский/Russian 1 26/06/2013 01:17 PM
Чтение файлов из папки ГТА у клиента coloN Русский/Russian 65 27/02/2013 10:04 PM
Чтение команд [HHT]DRON Русский/Russian 13 07/12/2011 05:13 PM
Чтение многостраничного файла -Stranger- Русский/Russian 7 29/07/2010 08:19 PM


All times are GMT. The time now is 05:21 AM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.