Подтвердить что ты не робот

Когда использовать R, когда использовать SQL?

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

Я больше знаком с R, чем с SQL, и я использую MySQL.

Мой вопрос:

В какой момент полезно прекратить увеличивать сложность оператора SQL в пользу функциональности подмножества данных в R (например, merge, *apply, maply, dlply и т.д.) в R.

С одной стороны, объединение SQL проще, чем выбор всего содержимого каждой таблицы и использование функции R merge для их объединения. Кроме того, выполнение условных выборок в SQL уменьшит объем данных, которые необходимо импортировать в R; но разница в скорости незначительна.

С другой стороны, большое объединение со сложным предложением where становится менее понятным, чем синтаксис R.

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

Меня интересует общий ответ о том, какие шаги должны использовать предложение SQL where, и какие шаги будет проще выполнить с помощью R.

Иллюстрация:

Описание базы данных

есть три таблицы: a, ab и b. Таблицы a и b имеют первичный ключ id. Они имеют много-много отношений, которые представлены таблицей поиска, ab, которая содержит поля ab.a_id и ab.b_id, которые присоединяются к a.id и b.id соответственно. Обе таблицы имеют поле time, а a имеет поле group.

Цель:

Вот минимальный пример соединения и подмножества, которые я хочу сделать,

(Именование наименований элементов, например a.id, эквивалентно a$id в R)

  • Объедините таблицы a и b с помощью ab, добавив несколько новых значений b.time, связанных с каждым a.id, в качестве нового столбца;

    select a_time, b.time, a.id, b.id from 
           a join ab on a.id = ab.a_id 
           join b on b.id = ab.b_id and then append b.time for distinct values of b.id;
    
  • Мне не нужны повторяющиеся значения b.time, мне нужно только значение b.max: для повторных значений b.time, соединенных с каждым a.id, b.max является значением b.time ближе всего, но не больше a.time

    b.max <- max(b.time[b.time < a.time))
    
  • добавьте значение dt <- a.time - b.max в таблицу, например, в R,
  • для каждого отдельного значения в a.group, выберите, какой (min (x.dt)))

    x.dt <- a.time - b.max
    
4b9b3361

Ответ 1

Я обычно делаю манипуляции с данными в SQL пока данные, которые я хочу, находятся в одной таблице, и затем, я делаю остальные в R. Только при наличии проблемы с производительностью я начинаю перемещать некоторые из вычислений в базу данных. Это уже то, что вы делаете.

Часто вычисления с использованием временных меток стать нечитаемым в SQL ( "аналитические функции", аналогично ddply, должны упростить это, но я думаю, что они недоступны в MySQL).

Однако ваш пример, вероятно, может быть полностью написан в SQL следующим образом (не проверен).

-- Join the tables and compute the maximum
CREATE VIEW t1 AS
SELECT a.id    AS a_id, 
       a.group AS a_group,
       b.id    AS b_id,
       a.time  AS a_time, 
       a.time - MAX(b.time) AS dt
FROM   a, b, ab
WHERE  a.id = ab.a_id AND b.id = ab.b_id
AND    b.time < a.time
GROUP  BY a.id, a.group, b.id;

-- Extract the desired rows
CREATE VIEW t2 AS 
SELECT t1.*
FROM t1, (SELECT group, MIN(dt) AS min_dt FROM t1) X
WHERE t1.a_id = X.a_id 
AND   t1.b_id = X.b_id 
AND   t1.a_group = X.a.group;

Ответ 2

Почему бы не и, и SQL, и R - внутри R, используя sqldf пакет? Эти examples показывают, как вы можете использовать функцию sqldf либо с помощью R-кадров данных, либо через соединение с существующей базой данных. Таким образом, у вас есть гибкость в том, что идиома сочтет нужным.