Quote:
Originally Posted by KrYpToDeN
Профиль:
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
2) Удобство чтения.
3) В случае чего можно очень быстро чтот поправить, сделать удобно выборку и тд.
|
Как выше уже описал, удобство если и будет, то только для скриптера. Для MySQL же наоборот количество действий увеличится пропорционально. Крайне сомнительно в данном случае жертвовать быстродействием ради того, чтоб запросы стали на 10 символов короче, ибо висящая БД = висящий сервер (по крайней мере жалобы на лаги вы точно себе обеспечите от игроков).
Quote:
Originally Posted by KrYpToDeN
В любое время можно изменить лимит 1 значением всего лишь.
|
В предложенном мной варианте так же можно оформить код так, чтоб увеличение лимита занимало лишь одно действие. Точнее, два: изменение константы в коде и создание нужного числа столбцов
(хотя и создание/удаление столбцов можно спокойно автоматизировать при старте сервера. Правда, вряд ли все усилия будут оправданы, так как лимит если и будет изменяться, то пару раз за всю жизнь сервера и проще вручную вносить изменения в структуру базы, чем писать для этого кучу дополнительного кода, который будет 99% времени срабатывать в холостую). Так что сомнительный плюс.
