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

Question

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

Я немного погуглил, но не нашел именно то, что искал по теме. Если у вас есть опыт с этим, я хотел бы услышать об этом.

Спасибо, Matt

Answer 1

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

Вы можете сделать что-то вроде:

CREATE TEMPORARY TABLE myTopCustomers
   SELECT customers.*,count(*) num from customers join purchases using(customerID)
   join items using(itemID) GROUP BY customers.ID HAVING num > 10;

А затем выполните несколько запросов к myTopCustomers без необходимости объединять покупки и товары по каждому запросу. Затем, когда ваше приложение больше не нуждается в дескрипторе базы данных, очистка не требуется.

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

Answer 2

Сначала отказ от ответственности - моя работа заключается в составлении отчетов, поэтому я сталкиваюсь с гораздо более сложными запросами, чем любой нормальный разработчик. Если вы пишете простое приложение CRUD (Create Read Update Delete) (это будет большинство веб-приложений), то вы действительно не хотите писать сложные запросы и, вероятно, делаете что-то не так, если вам нужно создать временные таблицы.

Тем не менее, я использую временные таблицы в Postgres для ряда целей, и большинство из них переведут на MySQL. Я использую их, чтобы разбить сложные запросы на ряд индивидуально понятных частей. Я использую их для согласованности - генерируя сложный отчет с помощью ряда запросов, и затем я могу разгрузить некоторые из этих запросов в модули, которые я использую в нескольких местах, я могу убедиться, что разные отчеты согласуются друг с другом. (И убедитесь, что если мне нужно что-то исправить, мне нужно исправить это только один раз.) И, редко, я намеренно использую их, чтобы вызвать конкретный план запроса. (Не пытайтесь делать это, если вы действительно не понимаете, что делаете!)

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

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

Answer 3

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

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

Answer 4

Если вы новичок в базах данных, есть несколько хороших книг Джо Келко, в которых рассматриваются лучшие практики для ANSI SQL. SQL For Smarties подробно расскажет об использовании временной таблицы, влиянии индексов, где предложения и т. Д. Это отличный справочник с подробными подробностями.

Answer 5

Я не делал их в MySQL, но я делал их для других баз данных (Oracle, SQL Server и т. Д.).

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

Я также часто использую их как средство «наклона» данных - превращение столбцов в строки и т. Д. Они хороши для расширенной обработки данных, но используют их только тогда, когда это необходимо. (Мое золотое правило, как всегда, применимо: если вы не знаете, почему вы используете x , и вы не знаете, как работает x , то вы, вероятно, не должны не используй это.)

Обычно я использую их чаще всего в sprocs, где требуется сложная обработка данных. Я бы хотел привести конкретный пример, но мой будет в T-SQL (в отличие от более стандартного SQL в MySQL), а также все они являются клиентским / рабочим кодом, которым я не могу поделиться. Я уверен, что кто-то еще здесь на SO подберет и предоставит некоторый подлинный пример кода; это было только для того, чтобы помочь вам понять суть проблемных временных таблиц домена.

Answer 6

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