оптимизация таблицы для хранения большого количества записей

[mixwell]

оптимизация таблицы для хранения большого количества записей

Доброй ночи, Господа. Скажите, пожалуйста, как лучше оптимизировать таблицу для хранения большого количества записей. Таблица будет принимать до 5000 записей в день и будет представлять из себя своеобразную внутреннюю почту.

 

[Mr_Max]

Если таблица

будет

то оптимизировать пока нечего.

[telepat_mode]
Ты имел ввиду, наверное, структуру таблицы
Тогда, наверное, нужно объяснить более подробно что ты реализуешь.

1-й таблицей ты не обойдешся.
Если это внутренняя система "общения"
то, как минимум
1-я таблица юзера
2-я таблица сообщения.
[/telepat_mode]

 

[mixwell]

Извиняюсь, что не конкретизировал.

idMail int(11) Нет auto_increment
title varchar(100) cp1251_general_ci Нет - заголовок
dataMail text cp1251_general_ci Нет - содержание письма
sexUserTo int(11) Нет - пол отправителя
idUserTo int(11) Нет - id отправителя
sexUserFrom int(11) Нет - пол получателя
idUserFrom int(11) Нет - id получателя
temp int(11) Нет 0 - статус письма, как временного
checkMail int(11) Нет - статус, одобренно ли письмо
mRead int(11) Нет - статус, прочитанно ли получателем письмо
statusDelM int(11) Нет - статус письма, как удаленного для мужчин
statusDelW int(11) Нет - статус письма, как удаленного для девушек
photo1 varchar(100) cp1251_general_ci Да NULL - адрес прикрепленной фото
photo2 varchar(100) cp1251_general_ci Да NULL - адрес прикрепленной фото
photo3 varchar(100) cp1251_general_ci Да NULL - адрес прикрепленной фото
dateMail date Нет - дата отправления
timeMail time Нет - время

-~{}~ 21.02.08 09:28:

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

 

[TutanXamoN]

mixwell
Надо бы ибо он слегка неадекватен).
Касательно задачи:
Вы знакомы с понятием избыточности? Зачем для каждого сообщения хранить пол получателя+пол отправителя+статус удалённый для мужчин и для женщин.
При грамотной реализации тормозить не будет.

 

[mixwell]

TutanXamoN, а как грамотнее хранить данные. Лучше вынести вторичные данные в отделую таблицу? Просто пол получателя, отправителя, статус удаленный. и т.д. хранить необходимо, чтобы идентифицировать письмо.

 

[melo]

вынести в отдельную таблицу, сделать связь по id.

 

[mixwell]

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

 

[Mr_Max]

mixwell

хранят миллионы, сотни миллионов записей

Наполеоновские замашки да?

Спустись, пожалуйста, на замелю и объясни нормально что ты хочещь? Какие задачи перед тобой стоят?

 

[mixwell]

собственно, я обьяснил. Задача проста - создать базу, которая будет хранить миллионы записей. В этом еть что-то наполеоновское? Например на сайте есть 200 пользователей, которые отправляют по 15 сообщений в день. это получается 3000 сообщений в день, 93000 сообщений в месяц и 1116000 сообщений в год. Это подсчеты с учетом средней нагрузки. Но из этого и нужно исходить, правильно?

 

[Mols]

Автор оригинала: mixwell
просто немного преживаю, не будет ли торомозить запрос к таблице, если в ней миллионы записей??

Это будет зависеть от запроса. Если нормально будут работать индексы особых проблем не будет. При добавлении новых записей конечно времени будет уходить больше. Но особых тормозов думаю тоже не будет.

Автор оригинала: mixwell Очень не хочется чистить перепику клиентов через какое-то время.

Чистить и не обязательно. Если уж очень хочется, то можно сделать таблицу архив(такой же структуры как и изначальная), в которую перемещать записи из первичной таблицы. Когда перемещать.. раз в какой-то период времени или при достижении в первичной таблице определенного числа записей смотрите сами.
Ну и дальше работать в запросах_на_чтение уже с двумя таблицами. Пока скорее всего через UNION. Когда нормально заработают представления - можно будет создать представление.(если я не ошибаюсь то на версии 5.0.24 меня чем-то не устроило как в подобной ситуации себя вели представления. Я тогда выбрал UNION. Может конечно ситуация уже изменилась )