例如，如果为我提供PostgreSQL数据库，那么使用RPostgreSQL与之交互而不是使用命令行或数据库管理应用程序执行SQL操作时，我会错过什么呢？有一些只能用SQL完成的事情吗？
抢先解决我对这个问题的先前迭代（example）的常见回答：我知道R和SQL是用于不同目的的不同工具。
答案 0 :(得分：1)
在将RPostgreSQL和RPostgres之类的R包与SQL命令行或数据库管理应用程序进行比较时，您根本没有限制自己。 R软件包可以提供与其他工具相同的类似命令行的界面，例如通过DBI启用dbExecute（），并且您可以发出所需的任何语句。更高层的包装器功能可能会带来差异，这可能会导致R和SQL之间的接口无法正常工作。这样的问题可能看起来像类/数据类型的解释（例如，我相信R包不知道如何解析postgresql数组数据类型作为一个特定的示例）。例如，这可能会影响upsert类型的命令或将完整data.frames追加到数据库表的调用，因为当更高级别的函数尝试错误地自动映射它们时，数据类型可能会不匹配；在必须将NA映射为NULL或显式转换数据类型时，也可能存在类似的问题。编写临时表和这种性质的东西也可能会有问题。我将这些更多地视作怪癖或烦恼，因为有一些变通办法可以实现相同级别的功能。例如，通过使用要求更全面地写出SQL的较低级函数调用；或通过其他工作来映射将在本机SQL和R环境之间转换的数据类型。 （我在其他地方回答了另一个SO问题，并提供了一个使用R和数据库之间的中间表的解决方法的示例：How to insert R dataframe into existing table in SQL Server）。从事务级别命令转移到更全面的DBA需求，例如管理用户，权限，基础配置等，也可能会发现一些限制。我还将注意到，尽管dplyr包可能会非常流行，但它提供了非常高级的便捷功能来与SQL交互，而不是直接编写语句和使用较低级别的包调用，它更有可能施加限制。 dplyr使用R函数调用自动构建SQL语句，但是尝试执行相对简单的select / insert / update / join样式调用以外的任何操作可能需要付出大量努力才能使所谓的快捷方式按预期执行。