SQLもdplyrも、使い分けができれば最強! ~完璧主義を捨てて「まずは使ってみる」文化を広めよう~
SQLとdplyr、どちらも覚えておいて損はない、そんな話だった気がする。いや、確かSQLってめちゃ強力だけど古い環境だとやたら冗長になったりして大変で…小さなデータ(たぶん七百弱くらい?)ならRのdplyrでサクッと処理した方が楽だったとか。実際、その時は可視化用データを作るためにdplyrを使ったような記憶。
あと、最初書いたSQLは回りくどかったみたい。でも列を明示しすぎず、ネスト一段減らして短縮できる、と途中で気付いた。最終的には十四行ぐらい?前よりずっとシンプルだったと思う。
R側もif_else()使えばcase_when()よりちょっとスッキリ…ってコメントもあったかな。counter作ってからすぐcumsumでSEQNO出せば六行程度まで短縮できて、小さな改善だけど知っておくと便利そう。data.tableにも少し触れてみたけど、何倍も速かった気がする。本格的にやるならDTの書き方覚えた方がいいのかも。でもまあ、この辺は状況次第ということで…
あと、最初書いたSQLは回りくどかったみたい。でも列を明示しすぎず、ネスト一段減らして短縮できる、と途中で気付いた。最終的には十四行ぐらい?前よりずっとシンプルだったと思う。
R側もif_else()使えばcase_when()よりちょっとスッキリ…ってコメントもあったかな。counter作ってからすぐcumsumでSEQNO出せば六行程度まで短縮できて、小さな改善だけど知っておくと便利そう。data.tableにも少し触れてみたけど、何倍も速かった気がする。本格的にやるならDTの書き方覚えた方がいいのかも。でもまあ、この辺は状況次第ということで…
本段の参照元: https://www.johnmackintosh.net/blog/2018-06-03-even-simpler-sql/
日本ならではのハードルと、私が実践で学んだ「ツール選びの本質」 ~エクセル依存・情報不足・完璧主義との向き合い方~
SQLとdplyrを日本で広めようとすると、いくつかの興味深い障壁に直面するかもしれません。まず、日本の企業は伝統的なシステムや既存のデータベース環境に強くこだわる傾向があり、新しいアプローチへの抵抗感が強いでしょう。また、データサイエンスの分野では、まだExcelやSASに慣れている中高年エンジニアも多く、Rの新しい手法を受け入れるには時間がかかりそうです。さらに、技術的な細かい部分にこだわる日本の文化特性から、パフォーマンスや細かい実装の違いについて、長々と議論が続く可能性があります。
