Должен ли я разбить одну таблицу на многих, если она будет часто посещаться?

Question

Прямо сейчас у меня есть стол для фотографий. Я ожидаю, что эта таблица будет сильно поражена. Улучшу ли я производительность, если разбью ее на 3 таблицы, если, например, у меня будет 3 разных типа фотографий? Или это не улучшит производительность?

Answer 1

Вы не говорите, какую базу данных вы используете. Это реляционная база данных SQL или один из хранилищ данных, отличных от SQL, таких как Hadoop, CouchDB, Redis или Tokyo Cabinet?

Для хранения фотографий я бы выбрал один из хранилищ данных, отличных от SQL, и не беспокоился о разбивке фотографий разных типов на разные таблицы.

Answer 2

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

Это не улучшит производительность, однако будет

• кошмар для управления
• заставит вас написать код спагетти
• сделает сообщения или дополнительные функциональные вызовы беспорядочными

Например, предположим, что вы пошли по маршруту и ​​создали три таблицы: Декорации, Портреты и Развлечения и загрузили фотографии в эти таблицы. Что происходит, когда вы добавляете другую категорию, собираетесь ли вы добавить другую таблицу? Надеюсь нет. Держите их все в одном столе. Добавить индекс в таблицу (ПК). Добавьте категорию в таблицу, чтобы классифицировать фотографии.

Answer 3

Я бы не стал так писать изначально. Однако, как уже упоминали многие, я бы добавил столбец категории. Это позволит вам разделить таблицу в будущем. Вот некоторая информация о разбиении таблиц в MySQL.

http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

Answer 4

У меня также есть идея сохранить их в одной таблице и добавить поле дискриминатора. Что другие не смогли упомянуть: добавьте индекс к этому полю!

Если (и только если) выбранные вами фильтры фильтруются в индексированных полях, производительность не сильно пострадает.

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

Answer 5

Я сильно сомневаюсь, что ваша таблица будет "поражена" достаточно раз, чтобы снизить производительность вашей базы данных. Я бы сохранил его как одну таблицу и, как указано выше, добавил столбец «Тип». С этим проблем быть не должно.

Answer 6

Я бы выбрал подход с одной таблицей со столбцом type, который содержит typeid или название ваших типов фотографий. Ваше предложение будет означать добавление / удаление / изменение таблиц в вашей базе данных, если вы решите внести изменения в типы ваших фотографий (например, добавление нового типа потребует создания новой таблицы. Yuck!).

Answer 7

если «попадание» означает чтение, и особенно если чтения используют поиск по первичному ключу, сохраните их в одной таблице.

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

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