dapengde 如果不新开一个分栏的话，我建议放 data.table 放在 B 栏，因为:

data.table inherits from data.frame. ... It is inspired by A[B] syntax in R where A is a matrix and B is a 2-column matrix.

这样就不必担心“无法贯穿 BT 全书”这个问题了。加到附录太委屈这个皮薄馅大的包了。

      Liechi dapengde 不要担心 data.table 属不属于 Base R？ 它绝对属于 Base R 阵营，因为人家的描述文件写的很清楚， Title: Extension of data.frame

            我倒是觉得 local 模式如果 base R 和 tidyverse 性能没差异，大家怎么写都无所谓。
            比较有建设性的是，在 cluster 模式如何处理 PB 级别数据。比如 base R 和 tidyverse 对比如何实现 word2vec之类的。
            比如数据分析以前很少有人处理过 nginx日志，通过 tidyverse 就提供了批量处理nginx日志的一个通道。

            因为透过 db 层的封装， tidyverse 成为了强大的分布式处理工具，比如通过 geospark, RPostGIS 处理各种空间数据。
            如果把 sf 归类到 base R ，在做大数据处理的时候差异还是蛮明显的。

            其他的一些 db，比如 neo4j, elasticsearch, mongodb 等等也会有一些奇葩功能是 base R 不会考虑的，所以我说这么比较有些不公平。

              dapengde 我看了HarryZhu-7harryprince 的两条回复之后，我觉得讨论 BT 首先要定义好什么是 Base R（B） 什么是 Tidyverse（T）？只有把这个定义好了才有后续的比较。我不想引发一些不必要的争论，我认为<https://github.com/tidyverse/> 和 <https://github.com/r-dbi> 是不同层面的两个东西，前者是 tidyverse 后者是和 tidyverse 无关的 R与数据库的接口集合。至于接口之上，用户层面写 SQL 语句（Base R 风格）还是写 tidyverse 风格的数据操作都无所谓，分布式，集群这些，甚至实时、高并发这些都不是 R 社区做的，是你说的Hadoop Spark PostGIS Redis Nginx 等数据处理、缓存、代理引擎做的， geospark, RPostGIS 都是其上的接口，这些接口需要解决如何与 Spark PostGIS 等的引擎交互，因为你想啊，传个 SQL 语句用的着 Nignx 代理 Redis 缓存 Hadoop 存储 Spark 处理吗？是用户请求和 SQL 语句的执行才需要。

              我对 ClickHouse 略有了解，它提供了 JDBC 和 ODBC 两种驱动，所以如果是传递 SQL， 那么简单的就只需要根据 DBI 包，将其抽象封装的接口实例化即可，这样就实现了 clickhouse-r，如果需要 tidyverse 风的数据操作，就需要进一步翻译 SQL 为 dplyr 式的操作，这个翻译的过程需要写 C++/C 代码（走 ODBC 驱动）或者 Java 代码（走 JDBC 驱动）。

              应该把 geospark sparklyr 看成一个前端，定义 dplyr 风格的操作，如果是直接基于 dplyr 就像你说的容易内存泄漏，这是显然的，因为一般人根本不知道它内部是什么？ 我也不知道，所以我很菜，当年在渣浪用的是 DBI 连接 ClickHouse 分布式集群，传递 SQL，报错了比较好调。

              这是我以前整理的一堆临时笔记，仅供参考 <https://bookdown.org/xiangyun/RGraphics/dm-import-export.html#import-data-from-database>

                    Cloud2016 啊哈哈，这本”BT擂台赛“原本没打算涉及这么深入的探讨。本来只是想搜集整理一下这里的提问和解答，帮助学习和使用而已，没想到扯到了站队问题。”只有把这个定义好了才有后续的比较“，这个态度严格上来说是对的，然而从实用角度来讲，不是”BT擂台赛“这本书的目的。如果在这一步纠缠不清，那么可能没法往下做了。你看人家 Thanos，一心一意想着打个响指灭掉一半生命，就把事儿给办了，没想着先定义一下什么是生命，人变成灰了可是身上的衣服怎么也灰了，同时体内的细菌病毒寄生虫算怎么回事儿……

                    不过，既然牵出这个话题，聊一聊也挺有意思的。

                    网上有不少关于 Base R vs. Tidyverse 的讨论（如这里，这里，这里，这里），我看他们就直接讨论下去了，没见到先定义的，可见，二者应该是有约定俗成的范围的。你猛一看觉得是 Base R 那就是 Base R。就擂台赛来说，如果需要界定一下的话，我觉得可以这样简单界定：

                    • B 方案：不需要require()或library()或foo::bar()就能实现的方案。
                    • T 方案：需要且仅需要require('tidyverse')而不需要加载其他包就能实现的方案。

                    这样可能更具有操作性。这也是我为啥没让 data.table 卷入的原因。

                    我理解的 Base R，就是 R 默认安装包（参考这里）：

                    • base
                    • compiler
                    • datasets
                    • graphics
                    • grDevices
                    • grid
                    • methods
                    • parallel
                    • splines
                    • stats
                    • stats4
                    • tcltk
                    • tools
                    • translations
                    • utils

                        dapengde
                        既然开始了，那就讨论一下。

                        其实我提出在 BT 擂台里加入 data.table，和站队无关，而是因为想起了 @Cloud2016 转发的 Mattlof 的文章。对文中的观点我不全认同，但是认为 data.table 值得拥有更多人知道这点，我无保留地支持。既然 BT 擂台“不是要他们分输赢，而是通过比较来强化我们对他们的理解和消化”，我想，在这个精神的指导下，加入 data.table 于比较的行列是件两全其美的好事：一来丰富了比较的多样性，让各系统的优劣充分展现；二来可以让更多人的了解 data.table 这个有很多优点的包。我觉得在数据整理部分为 data.table 单开一栏并无不可，不必拘泥于比较的对称性，即同时考虑作图和数据整理。不过既然考虑了这点，我想按照 data.table 的设计精神，将其划入 Base R 是自然的。如同建立系统发生树，总有合理的算法将“物种”聚类的。这个提议的初衷和站队无关，如果我觉得 data.table 和极乐净土更接近，也会毫不犹豫地提议将其划入 T 方案。

                        定义是重要的，在你举的 Thanos 的例子里，就算默认生命这个概念是自明的，但“一半”如何处理？是一个细菌等价于一个人这样算一半，还是按照体积或重量算的一半？如果现在设计一个函数帮助 Thanos 完成任务，定义的不清楚或许会让程序设计出现问题。你提出了你对 B 和 T 方案的定义，我想这表明你也至少部分认同定义边界是重要的。

                        我认同你对 T 方案的定义（考虑到极乐净土在一直囊括新包，不断扩张，其实这定义对 B 方案来说是不公平的；另外，管道这样本来中性的函数为管道所独占也不合理，它本不是专为 T 设计的，不过这些暂且先忽略），但我觉得 B 方案的定义太狭窄。在极乐净土出来之前，大家对 Base R 的理解和现在是很不同的。我想现在大家对 Base R 的理解一般为 “非 Tidyverse”。不过如果按照非 T 来理解 B 方案的话，似乎使得 B 方案有了无限可能，这有点耍赖：）会引发很多的问题，比如 lattice 作图要不要放到 B 方案里？但是我觉得加上一个设计精神源于 Base R，且功能强大，值得推广的 data.table 到 B 方案里应该是合理且有益的事情。

                        哈哈，突然想起最近看《西游记》时的一个感慨，“或许在天上佛道已然一家亲了，只苦了“愚昧”的世人，还在下界痴痴地守着分别心。”不过想想，世上很多事情都是由分辨始，至融汇终的（取其优点，秉承“拿来主义”），这也算世事的一个常态吧。

                            dapengde 我完全赞同你的BT之分的观点，tidyverse 是不含有 DBI 的，而 HarryZhu-7harryprince 可能长期泡在 tidyverse 和 sparklyr 的世界，已经有点模糊了，事实上， sparklyr 加载之后会自动从命名空间导入 DBI， 因为 sparklyr 是面向 spark 的接口包，没有这一层是无法传递 SQL 语句的，tidyverse 加载之后不会加载或从命名空间导入 DBI 包

                                  Liechi Cloud2016 data.table 我没用过，而且也没时间没兴趣试用—— Base R 已经解决了我所有的问题，额外学习 tidyverse 已经是很奢侈的事，我不想再花精力学别的可以完成同样工作的包了，DBI 更是用不着 。BT 这事儿要是有意义，诸位一起做才行啊！PR 或当合作者都行。

                                        dapengde 我对 github 不够熟悉，所以比较犹豫给别人发 PR，不过会尝试。要是操作不对，还请多包涵。

                                            离开了便利性问题谈功能，这个比较是有失偏颇的。按照研究套路，先定义清楚B和T，然后设定指标，对指标进行量化，最后通过分析得出结论。

                                            • B我认为就是刚装上R时候的那个状态。
                                            • 比较对象应试限于B和T功能上有交集的部分，不然没法比较。
                                            • 指标设定包括但不限于学习陡峭程度、代码可读性、处理速度、资源占用等。
                                            • 结论应该以数据为基础，避免主观偏好之间的无意义的舌战。

                                            以上个人愚见供参考。

                                            11 天 后
                                            1 个月 后

                                            dapengde 预览里”后记“链接失效了。可以从"title"部分点下一章进入”后记“，但目录处的”后记“超链接不工作。我克隆了这库，但是没有找到链接失效的原因，所以无法提出修改建议。

                                                dapengde 大鹏，你那个分列的语法，我查不到啊，我自己建了一个例子，加了下面那个:::cl text ::::没有用啊。

                                                
::: cl

Left block

:::

::: cr

right block
:::