Теория дизайна MySQL для 20000 записей

Question

Я хранил спортивную инвентарь в базе данных mysql. В presnt у меня есть 20 000 записей, около которых около 3000 являются текущими светильниками (в этом году). Текущие приборы, которые мне нужно будет регулярно получать, читать и обновлять, более старые приборы, которые мне нужны только для периодического доступа.

Так что мой план поставить текущие fictures в одну таблицу, а затем сохранить текущий прибор в другом:

fixtures_histroic fixture_current

Это хорошая практика, моя теория не тусклый придется трал через 20 000 записей, когда только 3000 возможных результатов. Затем, когда начинается новый сезон или год, я могу скопировать текущие светильники в историческую таблицу и начать новый ток.

Все это звучит хорошо на практике, мой следующий вопрос - как искать обе таблицы для данных. Я знаю, как сделать простое соединение, но рассмотрим этот запрос, как бы я запросил как matches_current, так и matches_histroic. Запрос уже сам по себе является объединением, поэтому это будет объединение объединений. Похоже, это может быть довольно грязно?

SELECT `m`.*, `h`.`name` AS "homeTeam", `a`.`name` AS "awayTeam", `o`.* 
FROM `matches_current` m 
JOIN `teams` `h` ON `m`.`home_team_id`=`h`.`team_id` 
JOIN `teams` `a` ON `m`.`away_team_id`=`a`.`team_id` 
JOIN `outcomes` `o` ON `m`.`score_id`=`o`.`outcome_id` 
WHERE `home_team_id`=1 AND `away_team_id`=2 
AND `m`.`score_id`>0 
ORDER BY `date` DESC 

Так что я делаю правильно, или я должен просто положить все 20 000 записей в один стол?

Вы заранее заблаговременно,

Alan.

Answer 1

Lousy idea. 20 000 записей не очень много. Вероятно, вы можете делать то, что хотите, с хорошей схемой индексирования данных. И разделение одних и тех же данных на несколько таблиц создает проблемы для обслуживания, безопасности, резервного копирования и целостности данных.

Единственные причины, по которым вы сделали бы это при таком небольшом числе записей, были бы, если бы размер записи был чрезмерно большим. Таким образом, даже если записи составляли 10 000 байт, тогда общее пространство, занимаемое таблицей, было бы всего 200 Мбайт, что по-прежнему мало по стандартам базы данных.

Если у вас было больше строк и вы хотели справиться с этой ситуацией, я бы рекомендовал разделить таблицу, а не создавать другую таблицу.

Answer 2

Что касается Вашего «первый» вопрос, сохраняя «исторические» и «текущие» данные отдельно:

Я не думаю, что это будет иметь какой-либо положительный эффект, учитывая у вас будет такое небольшое количество строк. Напротив, это значительно усложнит ситуацию ...