Как мое приложение может воспользоваться временными таблицами?

Ответ 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, не делая приемов для покупок и элементов для каждого запроса. Затем, когда вашему приложению больше не нужен дескриптор базы данных, очистка не требуется.

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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