Одна или несколько таблиц блога

Я создаю классический php-блог и сталкиваюсь с дилеммой относительно подхода single или двух таблиц mysql.

В первом случае настоящие блоги будут помещены в таблицу actual (максимум 100 строк), а заархивированные сообщения - внутри таблицы archive (максимум 20 000 строк).

Обе таблицы имеют одинаковую структуру.

Запросы к таблице actual выполняются очень часто, а к таблице archive - не так часто.

Но иногда встречаются запросы join и union, охватывающие обе таблицы.

Логично, что производительность намного лучше на меньшей таблице, но - достаточно ли этого в моем случае для создания двух таблиц вместо одной?

Есть и третье решение - единая таблица с двумя разделами actual - 100 rows и archive - 20.000 rows.

Что делать?

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

James Lingham 11.04.2018 13:31

Добавить поле достижения вместо создания таблицы с той же структурой

Nadeem Shaikh 11.04.2018 13:33

@JamesLingham, да, я, конечно, могу.

blueSky 11.04.2018 13:33

@NadeemShaikh, это замедлит мои запросы?

blueSky 11.04.2018 13:34

@blueSky Это было бы моим предложением, но на самом деле я не эксперт в таких вещах, возможно, стоит посмотреть, что говорят другие люди. Есть ли особая причина, по которой вы хотели бы избежать чего-то подобного?

James Lingham 11.04.2018 13:34

@JamesLingham, я понимаю, большое спасибо.

blueSky 11.04.2018 13:38

Бессмысленно иметь две таблицы с идентичной структурой, но одну для архивирования, а другую для «живых» записей. Таблицы не похожи на каталоги / папки. Хранилище MySQL не будет работать так, как вы интуитивно думаете. Имея единую таблицу, создайте столбец archived с 1 и 0 для статуса. Что будет делать разбиение на такое крошечное количество записей? Куда вы его разделите? Тот же драйв? В чем тогда смысл?

N.B. 24.04.2018 22:56
0
7
37
2

Ответы 2

Вы написали:

Logically, performances are much better on a smaller table

При всем уважении, ваша интуиция на этот счет - совершенно неверно для таблиц, содержащих менее десяти миллионов строк. Цель SQL - обеспечить быстрое извлечение нескольких элементов из многих. Тысячи лет программистского труда (не преувеличение) ушли на то, чтобы сделать такие вещи очень быстрыми. Вы не сможете перехитрить эти коллективные усилия.

Сложите предметы в одну таблицу. Если вам нужно различать активные и неактивные элементы, создайте столбец с именем active или что-то в этом роде и извлеките их с помощью WHERE active=1 или другого такого термина запроса.

Если вы считаете, что у вас проблемы с производительностью, вы можете добавить индексы в свои таблицы. Прочитайте это. https://use-the-index-luke.com/

Спасибо за ваше объяснение. Кстати, индексирование или разбиение на разделы - что лучше с точки зрения производительности?

blueSky 11.04.2018 13:42

кроме того, действительно ли вы уверены, что where active = 1 в строках 20.000 выполняет запрос настолько быстро, что нет существенной разницы по сравнению со строками 100 без этого предложения?

blueSky 11.04.2018 13:46

Разбиение на разделы имеет смысл только тогда, когда у вас 10 ^^ 8 или более строк. Настраивать и поддерживать очень сложно, и все запросы, кроме тщательно разработанных, становятся очень медленными (из-за сложности индексации). И да, я уверен, что правильно проиндексированные запросы к таблицам размером в двадцать киловатт выполняются быстро. Они быстрее запросов к крошечным таблицам? Возможно, но любая разница находится на уровне миллисекунды или ниже. Измеряйте успех своего проекта в количестве публикаций в месяц (время разработки и отладки), а не в количестве публикаций в микросекунду (необработанное время извлечения). Найдите аббревиатуры KISS и YAGNI.

O. Jones 11.04.2018 13:52

вы наверное имеете ввиду are they slower вместо are they faster?

blueSky 11.04.2018 13:58

При разработке баз данных не думайте только о том, как вы будете хранить данные; но подумайте обо всех возможных случаях:

  • Как вы собираетесь получать и обновлять информацию?
  • Будут ли разные представления и разные разрешения для разных люди?

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

да, но этот subset - это строки 20.000, а main set - только строки 100.

blueSky 11.04.2018 14:05

Никаких современных dbms не беспокоит. Если шкала в десятках миллионов, то вам стоит забеспокоиться.

Abhishek Keshri 11.04.2018 14:06

Другие вопросы по теме