R 和 SQL 是两个完全不同的野兽。SQL 是一种语言，您可以使用它来查询存储在数据库中的数据，正如您已经体验过的那样。SQL 与 R 相比的优势主要在于数据库服务器（MS SQL、Oracle、PostgreSQL、MySQL 等）这一事实。

大多数（如果不是全部）现代数据库服务器允许多个用户从同一数据源查询数据，并在同一表中插入、更新和删除数据，同时确保数据保持一致。这对于记录银行交易至关重要。你能想象在 R 上经营一家银行吗？这就是数据库服务器的用武之地。它们确保过程的 ACID 属性在数据库上运行。ACID 代表原子性、并发性、隔离性和持久性（参见wikipedia 上的 ACID 描述）。R 是一个单一用户平台，一切都发生在内存中。因此，如果您的计算机在大操作中途停止工作，您的数据将不会被存储。您也是唯一可以访问数据的人。需要明确的是，R 不被视为数据库服务器和/或 SQL 的替代品。

数据库服务器的另一个主要优点是良好的数据库设计将确保您可以通过执行查询优化来快速查询数据库。为了实现这个数据库服务器跟踪设计了一个表。有关此主题的完整讨论，请参阅wiki 页面。R 无法执行查询优化。糟糕的数据库设计会导致查询执行速度变慢。如果在数据库设计中正确使用了外键，数据库服务器还可以对查询多个表的查询执行优化。

SQL 语言的语法非常不同，我分享您的经验，即使用数据表或 dplyr 语法编写数据处理步骤更短。但是，有时您的数据对于 R 来说太大了，或者您需要将结果存储在数据库中作为定期批处理作业的一部分，这需要在 SQL 中编写您的逻辑。

根据我的经验，SQL 和 R/Python 有一些特殊的用例。SQL 非常适合存储关键业务数据以及允许多人在集中式环境中访问、修改、插入和删除数据。对于任何一次性数据处理，R 和 Python 都很棒。如果需要定期执行数据处理，则需要将 R/Python 脚本移植到 SQL。

这些甚至没有可比性，真的。SQL 是一种用于访问数据的语言，R 是一种用于处理数据的语言。

SQL 不是一个有效的修改工具，因为它很难看到中间步骤，并且当它抛出错误时，它不太可能解决数据的形式/质量/结构。

我的工作流程通常是：

1. 从 SQL 查询中获取原始数据（在 R 中）
2. 建立 munging 例程
3. 如果可能，重写 SQL 查询以完成我在 R 中完成的修改

还要意识到并非所有数据消费者都使用 R，但许多人仍然使用 SQL 将他们选择的平台与数据连接起来。

根据我的经验，HEITZ 提到的 1.、2.、3. 方法可能会扩展为 3. 的替代方法，您可以将数据从 R（data.table）写回 MySQL。

所以完整的步骤是 MySQL->data.table->MySQL

如果您确保在不复制 DT 的情况下使用 data.table 语法，那么它也对 RAM 友好。

library(dbplyr)有正确的方法：在 R 中编写所有内容（使用 tidyverse）并让库及时将 R 代码“编译”为低级 SQL。

由于并非所有 munging 都是可翻译的，SQL Server 采用了另一种方法：让 R 代码片段从 SQL“选择”命令中调用。