Как быстро создавать рекламные запросы?

Question

Я использовал Excel PivotTable для анализа данных из моей базы данных, потому что он позволяет мне «нарезать и кубиком» очень быстро. Поскольку мы знаем, что есть в наших таблицах базы данных, все мы можем писать SQL-запросы, которые делают то, что делает сводная таблица.

Но мне интересно, почему Сводная таблица может строить запросы так быстро, пока не знает ничего о данных и значениях/отношениях между полями данных, которые мы даем?

Задайте вопрос по-другому, как мы можем построить ad-hoc SQL-запросы столь быстрым и эффективным способом? («Используйте сводную таблицу, конечно!», Да, но то, что я хочу, является программным способом).

Answer 1

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

Excel быстрый, потому что все данные хранятся в памяти, и их можно сортировать быстро и эффективно.

Answer 2

Мое интуитивное чувство подсказывает мне, что ответ будет что-то делать с Pivot Table контуром, который имеет фиксированное количества зон, а именно:

- the Page Fields zone 
- the Column Fields zone 
- the Row Fields zone and 
- the Data zone 

В моей дикой догадке:

- The Page zone builds the WHERE part of the ad-hoc query. 
- The Column zone will put whichever fields drag-dropped to it in the GROUP BY clause. 
- The Row zone will build a SELECT DISTINCT <field names> 
- The Data zone will apply an AGGREGATE function to the field drag-dropped to it. 

Как вы думаете, что произойдет «за сценой», когда мы перетаскиваем поля в эти зоны?

Answer 3

@Mark Ransom определенно находится на чем-то с понятием Excel, хранящим данные в памяти, что делает его более быстрым вычислительно. Также возможно, что Excel предварительно индексирует наборы данных таким образом, чтобы сделать его более отзывчивым, чем ваша база данных.

Существует одна существенная, неагрессивная возможность для того, почему это происходит быстрее: Excel в использовании сводной таблицы не имеет понятия о соединении. Когда вы извлекаете данные ad hoc из своей базы данных, любые объединения или корреляции между таблицами приведут к дальнейшим поискам, сканированию, нагрузкам индекса и т. Д. Поскольку Excel имеет все данные в одном месте (ОЗУ или нет), он может выполнять поиск без предварительной подготовки наборов данных. Если бы вы загрузили данные своей базы данных в временную таблицу, было бы интересно увидеть, как специальные запросы к этой таблице сложены, по производительности, против Excel.

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

 
+--------+  +---------+ 
|tblUsers|  |luGenders| 
+--------+  +---------+ 
|userID |  |genderID | 
|genderID||gender | 
+--------+  +---------+ 

SELECT * FROM luGenders; 
> 1 Female 
> 2 Male 

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

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

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

Я настоятельно рекомендую The Data Warehouse Toolkit. Для записи я не администратор базы данных, я просто скромный аналитик, который тратит 80 часов в неделю на обработку Excel и Oracle. Я знаю твою боль.