|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго дня||ночи.
С MySql столкнулся впервые, поэтому прошу совета.
Задача:
Есть
Игрок (Логин, Пароль, список Чаров...).
Чар (Имя,Параметры ...)
Инвентарь (Предметы(только ID))
Как енто все представить ввиде таблиц.
Мой взгляд-
1. Таблица:
зарегестрированые игроки, они хранят дату регистрации, логин, пароль. и ссылки на чаров.
2. Таблица:
Чары, раса,левел, ссылку на инвентарь.
3. Таблица:
Инвентарь-список предметов (ID);
Проблема: думаю добавление/удаления предметов в инвентарь будет долгим.
Читаю книжки, доки, про сущности итд, внешние ключи..... но врубиться пока не смог, как и сколько мне нужно таблиц.
Обращения к базе, Регистрация, Коннект/проверка логин/пароль, загрузка данных. сохранения.
т.е. постоянных запросов нет.
Неактивен
Есть отношения 1 к одному, есть 1 ко многому и есть много ко многому.
Понятия ссылки на список в MySQL нет. Отношение 1 ко многому реализуется иначе: в таблице чаров хранится ссылка на игрока, которому принадлежит чар, при этом в таблице игроков никакой ссылки на чаров нет.
Если инвентарь у чара один, то это не отдельная вещь. Достаточно в таблице хранить
id чара, id предмета
и так для каждого предмета каждого чара отдельная строчка
id чара должен быть ключем, чтобы Вы могли быстро найти все предметы данного чара
Неактивен
>>Если инвентарь у чара один, то это не отдельная вещь. Достаточно в таблице хранить
>>id чара, id предмета
>>и так для каждого предмета каждого чара отдельная строчка
>>id чара должен быть ключем, чтобы Вы могли быстро найти все предметы данного чара
Вот это меня и смущяет. Получается - есть несколько огромных таблиц, понятное дело что в память целиком их не впихнешь. Получается, очень медленая вставка(удаления). в Отличие от к примеру на каждого свои таблицы, это конечно не вариант.
К примеру - зарегистрировано (600 000 юзверей), в Онлайне 1000, как поведет себя такая архитектура?
Не будет ли сильно тормозить..
Большое сенкс! Туман исчез.
Неактивен
Оцените насколько часто происходит запись/удаление и напишите ботов, которые юзеров имитирют и пусть вставляют/удаляют через определенный интервал. Запустите их 1000 
Можете при логине копировать инвентарь в отдельную таблицу, а при логауте возвращать назад. Тогда, в случае InnoDB вся таблица влезет в память, а в случае MyISAM вся влезет в кэш ключей (так как всего 2 поля чар, вещь, можно создать составной ключ из двух полей).
Неактивен
>>Можете при логине копировать инвентарь в отдельную таблицу, а при логауте возвращать назад.
Эта мысль.
Но все же пока не могу понять --- к примеру есть все те же 600к зарегистриров пользов. у каждого по 3 чара, у каждого чара 40 предметов.
получается MySql нужна сделать выборку из более 72лямонов.
Я конечно проверю, но думаю здесь ее и индексы не спасут, хотя все нужно протестить.
Отредактированно VladimirSobol (30.03.2008 00:02:28)
Неактивен
Скорость доступа по индексу пропорциональна log(числа элементов), так что индекс отработает быстро. Другое дело, что все эти записи будут в разных областях диска и в кэш не влезут.
Неактивен
>>Скорость доступа по индексу пропорциональна log(числа элементов), так что индекс отработает >>быстро. Другое дело, что все эти записи будут в разных областях диска и в кэш не влезут.
В кэш чего? надеюсь MySql. не захочет всю таблицу загрузить в память?
Неактивен
1. в кэш диска
2. в кэш mysql
не захочет, так как размер кэшей ограничен в конфиг-файле, см. темы в разделе Оптимизация
Неактивен
>>1. в кэш диска
Ну енто не так страшно.
>>2. в кэш mysql
>>не захочет, так как размер кэшей ограничен в конфиг-файле, см. темы в разделе Оптимизация
Да, знаю что ограничен, но не знал, как поведет себя MySql...
Ok. большой сенкс.
Неактивен
