Если вы строите значительную кодовую базу всей организации в R, приемлемо ли использовать платформу sqldf в качестве подхода по умолчанию для задач перебора данных? Или лучше всего полагаться на операции с синтаксисом R, где это возможно? Опираясь на sqldf, вы вводите существенное количество другого синтаксиса SQL в свою базу кода R.sqldf и ремонтопригодность базы кода R
Я задаю этот вопрос с особым учетом ремонтопригодности и стиля. Я искал существующие руководства в стиле R и ничего не нашел по этому вопросу.
EDIT: Для уточнения рабочего процесса я озабочен, рассмотрим munging данных скрипт делает достаточно использовать sqldf следующим образом:
library(sqldf)
gclust_group<-sqldf("SELECT clust,SUM(trips) AS trips2
FROM gclust
GROUP BY clust")
gclust_group2<-sqldf("SELECT g.*, h.Longitude,h.Latitude,h.withinss, s.trips2
FROM highestd g
LEFT JOIN centers h
ON g.clust=h.clust
LEFT JOIN gclust_group s
ON g.clust=s.clust")
И такой сценарий может продолжаться в течение многих линий. (Для тех, кто знаком с Hadoop и PIG, стиль на самом деле похож на скрипт PIG). Большая часть работы выполняется с использованием синтаксиса SQL, хотя это позволяет избежать сложных подзапросов.
Является ли эффективность проблемой? Если да, это не очень хороший выбор, и, безусловно, это не так просто, чтобы вы могли хранить «sql» код отдельно и называть его с помощью 'readLines'. – agstudy
Если у вас есть и sql-фон, возможно, вы можете исследовать пакет 'data.table', который имеет более приличный рабочий поток и имеет некоторую аналогию с sql. (Читайте faq 2.16) [[http://cran.r-project.org/ Web/пакеты/data.table/виньетки/DataTable-faq.pdf]. – agstudy
Я бы подумал о ремонтопригодности, 'dplyr' предпочтительнее, поскольку он использует SQL или другие внешние хранилища и накладывает одинаковый синтаксис для всех, с аналогичными операциями для внутренних таблиц, например,' data.frame', 'data.table'. –