Вопрос по чтение и сравнению
#12

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

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

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

UPD2: Несомненно, если стоит задача написать систему с неограниченным числом персонажей, то вариант KrYpToDeN будет гораздо оптимальнее. Но такой задачи не стоит и у нас есть вполне вменяемое количество персонажей, которых гораздо проще хранить в таблице с аккаунтами, а не терзать всякий раз таблицу персонажей лишь затем, чтоб понять, создал ли игрок хоть одного персонажа или нет.
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)