2010-03-10 3 views
0

Я пытаюсь построить проект базы данных mysql для проекта. Проблема заключается в лучшем решении. В основном в моем приложении мне придется вставить примерно 10-30 строк на пользователя. Первичным ключом будет случайная строка CHAR (16). Также будет указатель даты и времени, а также дополнительная строка (с индексом), называемая «данные».Дизайн базы данных

С каждым днем ​​на столе будет большое количество вставок и поисков. Поисковые запросы всегда будут объединены на основе первичного ключа (таким образом, объединение этих 10-30 строк на пользователя).

Иногда я буду иметь возможность посмотреть несколько месяцев (или даже полный год) и использовать функции mysql GROUP BY по индексу «данные».

В текущем объеме и оценках я ожидал, что таблица вырастет на 9,3 м строк в месяц. Я ожидаю, что это увеличится.

Итак, мой вопрос сводится к следующему: разделы mysql, разделение программных разделов или другое решение? и что лучше всего разделить на месяц или год? Мы работаем на RHEL, поэтому получение mysql 5.1 может немного работать, но если это лучшее решение, то это может стоить того.

innoDB уже выбран для этого проекта. Первичная задача - повседневная работа.

ответ

0

Разделяйте данные по датам (и, возможно, дополнительно пользователю это данные для каждого пользователя, и у вас много пользователей).

Затем создайте ежемесячную таблицу с SUM, COUNT, AVG и т. Д., Которые вам нужны, и соответствующую группу. Вы также можете разбить эту таблицу (но даты, вероятно, не будут значимым разделом)

Затем создайте годовую таблицу, такую ​​как ежемесячная таблица.

Заполнение ежемесячных и годовых таблиц с помощью REPLACE INTO ... SELECT ... утверждений.

2

Это не ответ на ваш вопрос, но это должно быть упомянуто ...

Первичный ключ будет случайным CHAR (16) строка.

Это плохая идея. Используйте столбец UNSIGNED BIGINT с AUTO_INCREMENT. Не нужно изобретать колесо: вам не придется беспокоиться о ключевом управлении или конфликтах.

+1

Согласитесь, если каким-то образом ключ не может быть автоматическим приращением, вы можете использовать алгоритм генерации ключа Hi-Lo. –

+0

Я знаю об автоматическом приращении, но слияние таблиц с последовательными идентификаторами будет больно. – jwzk

+1

слияние таблиц с «случайными» идентификаторами будет большой болью, особенно когда есть дубликаты! –

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