2009-12-11 2 views
1

Я в ситуации дилеммы. Я не уверен, что хорошая идея отделить таблицу пользователей. Я замечаю, что мои игры играют в рекордах стола, поскольку число растет, загрузка становится все медленнее и медленнее.Таблица нескольких пользователей таблицы VS 1 пользователей?

В таблице моих пользователей хранятся все пользователи, которые в настоящее время составляют около 10 тыс. Пользователей. Я имею в виду разделения таблицы пользователей (на будущее) в подобных:

Войти Таблица => магазин пользователя регистрационные данные

========================================== 
= id | username | password | tableid = 
========================================== 
= 1 | user1 | user1xx | 1  = 
= 2 | user2 | user2xx | 1  = 
... 
= 20k1 | user20k1 | user20k1 | 2  = 
etc 

пользователей Данные

========================================== 
= id | money | items | preferences = 
========================================== 
= 1 | xx | xx | xx  = 
= 2 | xx | xx | xx  = 
... 
= 20k1 | xx | xx | xx  = 
etc 

Так что, когда я пытаюсь получить данные пользователей Я просто LEFT JOIN запрос, чтобы получить данные.

Мой вопрос: существуют ли различия (скорость, производительность и т. Д.) Между хранением данных пользователей в нескольких таблицах и хранением данных пользователей в одной таблице? (Предположим, что индексы и первичный ключ одинаковы)

Мои текущие таблицы индексов:

Игры Рекорды стол => столбцы: идентификатор, GameID, имя, оценка, дата

Первичный ключ: идентификатор

Индексы: GameID

Вход Таблица => Столбцы: ID, имя пользователя, пароль

Первичный ключ: идентификатор (идентификатор)

Индексы: Имя пользователя

пользователей данных => Колонки: alots

Индексы: идентификатор

ответ

1

Похоже, что настоящий вопрос, который у вас здесь есть, заключается в следующем: почему приложение ma медленно. Прежде всего, разделение данных между несколькими таблицами не поможет повысить производительность. Если все сделано правильно (по причинам, отличным от производительности), это не повредит работе, но я сомневаюсь, что это поможет.

Более того, по моему опыту, это плохая идея для оптимизации на основе чувства кишки. Как-то догадывается о том, что удерживает вашу программу обратно, как правило, неправильно. Вы в конечном итоге делаете много переписывания без какого-либо выигрыша в скорости.

Первым шагом, чтобы ускорить это, является поиск реального узкого места. Вам нужно добавить инструментарий и собрать некоторую статистику, чтобы понять - это база данных или сервер приложений. Это конкретный sproc или может быть пропускной способностью вашей сети. Или может быть, это некоторые javascript на ваших страницах.

Только после того, как вы знаете, что исправить, вы можете исправить это.

0

Если вы запрашиваете для битов информации и у вас есть много (редактировать:) столбцы, это на самом деле очень хорошая идея, чтобы они были разделены, и вам не нужно поле tableid в таблице users, все, что вам нужно, это внешний ключ в информационной таблице, который указывает на связанного пользователя в таблице users.

Вы можете использовать несколько таблиц и присоединяться к ним по своему усмотрению, производительность, скорее всего, возрастет.

1

Похоже, что разделение стола не принесет вам пользы. Кажется, что между таблицами будет иметь место соотношение 1: 1, и это просто добавит второй запрос, когда вы захотите что-то из этой таблицы.

Попробуйте использовать Partitioning на столе, чтобы помочь с производительностью в этом аспекте.

Нормализация полезна только при наличии избыточных данных (так что у вас один и тот же пользователь в вашей пользовательской таблице 5 раз). Полезно, если вы хотите снизить использование данных с высокими баллы пользователей для нескольких игр, но в конечном итоге это, вероятно, не даст вам увеличения производительности на столе.

Смежные вопросы