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
:::

                                        看了一眼大鹏的repo提一下建议：

                                        我觉得bookdown不适合作为BT擂台赛的平台，blogdown可能更适合一点。一来netlify+github的实时编译发布比起bookdown方便及时，一个新帖子对应一个运用实例+不同解决方案可以不断更新，二来gitbook模板单一可发挥的余地不多，hugo模板漂亮多了ww三来blogdown的tag categories等分类功能也可以方便地自动建立不同运用实例之间的关系，如 可视化/数据清理 这样的大致分类

                                        还有大鹏那个bookdown项目因为用了双栏布局，好多长代码快还多了个水平方向的拖动条，观感并不好。

                                        还有代码能加注释更好吧…

                                          tctcab 有道理。开始的时候我想过要不要换成别的形式，后来就搁置了，主要原因是懒得在形式上花更多精力，以及目前内容就那么一点点。

                                          从方便及时角度来说，现在是 travis 自动实时编译的，还算快。

                                          hugo 模板确实丰富漂亮，只是又得挑又得改的，麻烦。

                                          tag categories 当然会方便读者，不过就目前这么点儿内容， 暂时用不着吧。况且，这个项目能不能更新下去都不好说……

                                          长代码我会尽量弄短换行，消灭横滚条。

                                          代码加注释可以有……

                                          好吧，总之我就是懒。

                                          有空的话就 PR 些内容过来呀。等内容丰富了，再调整形式也不迟。

                                              dapengde

                                              要内容的话，我之前回答过的问题都有些记录，有空我整理一下pr过去
                                              https://github.com/tcgriffith/cosx_exps

                                              还有另一个可能的平台是wiki的形式，github那种，想参与的小伙伴直接编辑就行，省去了github克隆来叉过去的操作。

                                              另外如果嫌麻烦是主要难点的话，我就抽空去把blogdown的架子搭起来试一试

                                                  tctcab 你这个问答记录整理得真棒。我以后也这么干。

                                                  主要难点其实是怕雷声大雨点小。怕先搭好个大戏台，结果讲了个段子就完了。

                                                      dapengde

                                                      我在想怎么通过自动化来偷懒…
                                                      比如一周拿爬虫扫一遍cos论坛找有用的帖子…

                                                          tctcab 可行。只要在问题答完之后，把问题和解答整理一遍，按设计好的格式发个总结帖即可。爬虫就抓这个总结帖。

                                                          不过，这恐怕没有减少多少工作量。