最新のRおよび/またはPythonライブラリはSQLを廃止しますか？

私は、SQL Serverがデータ処理からクリーニング、変更まで、私たちが行うすべてのバックボーンであるオフィスで働いています。私の同僚は、着信データを標準化してレポート、視覚化、および分析プロジェクトで使用できるように、複雑な関数とストアドプロシージャの作成を専門にしています。ここから始める前は、最も基本的なクエリを書くことは別として、SQLの経験はほとんどありませんでした。私の分析準備作業の大部分はすべてRで行われました。上司は、Rを使用してより効率的かつはるかに少ないコード行では実行できない割り当てが非常に少ないように思えても、SQLスキルを向上させると主張していますdplyr、data.table、tidyrなどのパッケージ（いくつか例を挙げると）。私の質問は、これは理にかなっていますか？

数週間前、特定の条件を満たすテーブル内の各行の列名のリストを取得し、それらを文字列のベクトルに連結するタスクに直面しました。厳しい締め切りがあり、その時、私はいくつかの閉塞を経験していたので、問題を完全に解決することができませんでした。上司に尋ねたところ、上司は同僚に問題を解決するためのスクリプトTSQLを書くように頼みました。彼がそれに取り組んでいる間に、私はRでそれを行う方法を見つけて、かなり単純な関数を作成し、それをデータフレームに適用しました。私の同僚は、約2時間後にスクリプトで戻ってきました。ネストされた2つのforループを含む少なくとも75行でした。私は彼に、実行が終了したときに通知するように頼み、数時間かかると言いました。一方、私のRスクリプトは、約30秒で〜45,000レコードをループできました。

データのクリーニングと変更には、Rのほうがはるかに良い選択だと思いますか？おそらく私のオフィスのSQL開発者は不適当でしょうか？RとSQLの両方（またはPythonとSQLの両方）を扱った人がこれについて何か考えを持っている場合、私は興味があります。

RとSQLは、まったく異なる2つの獣です。SQLは、既に経験したとおりにデータベースに保存されているデータを照会するために使用できる言語です。SQL対Rの利点は、主にデータベースサーバー（MS SQL、Oracle、PostgreSQL、MySQLなど）の事実にあります。

すべてではありませんが、ほとんどのデータベースサーバーでは、複数のユーザーが同じデータソースからデータをクエリし、同じテーブル内のデータを挿入、更新、削除して、データの一貫性を保つことができます。これは、たとえば銀行取引を記録するために不可欠です。Rで銀行を経営することを想像できますか？そこでデータベースサーバーが登場します。データベースでプロシージャのACIDプロパティが実行されるようにします。ACIDは、原子性、同時実行性、分離性、および耐久性を表します（ウィキペディアのACIDの説明を参照）。Rは、すべてがメモリ内で発生するシングルユーザープラットフォームです。そのため、大規模な操作の途中でコンピューターの動作が停止した場合、データは保存されません。また、データにアクセスできるのはあなただけです。明確にするために、RはデータベースサーバーやSQLの代替とは見なされません。

データベースサーバーのもう1つの主な利点は、適切なデータベース設計により、クエリの最適化を実行してデータベースを高速にクエリできることです。このデータベースサーバーを実現するには、テーブルの設計を追跡します。このトピックの詳細については、wikiページを参照してください。Rはクエリの最適化を実行できません。データベースの設計が適切でないと、クエリの実行が遅くなる可能性があります。データベースサーバーは、外部キーがデータベース設計で適切に使用されている場合、複数のテーブルをクエリするクエリに対して最適化を実行することもできます。

SQL言語の構文は非常に異なるため、データテーブルまたはdplyr構文を使用してデータ変更ステップを記述する方が短いという経験を共有しています。ただし、データがRに対して大きすぎる場合や、定期的なバッチジョブの一部としてデータベースに結果を保存する必要がある場合があり、SQLでロジックをコーディングする必要があります。

私の経験では、SQLとR / Pythonの特定のユースケースがあります。SQLは、ビジネスに不可欠なデータを保存し、集中環境で複数のユーザーがデータにアクセス、変更、挿入、削除できるようにするのに最適です。一度限りのデータを変更するには、RとPythonが最適です。データ変更を定期的に実行する必要がある場合は、R / PythonスクリプトをSQLに移植する必要があります。

これらは、実際に比較することさえできません。SQLはデータにアクセスするための言語であり、Rはデータを操作するための言語です。

SQLは中間ステップを見ることは難しく、エラーをスローすると、データのフォーム/品質/構造に対処する可能性が低いため、変更するのに効果的なツールではありません。

私のワークフローは通常：

1. SQLクエリから生データを取得（R）
2. 修正ルーチンの構築
3. 可能であれば、SQLクエリを書き直して、Rで行った変更を完了します。

また、データのすべてのコンシューマーがRを使用するわけではありませんが、多くのユーザーは依然として、選択したプラットフォームをSQLを使用してデータとインターフェースしています。

library（dbplyr）には正しいアプローチがあります：Rですべてを（tidyverseを使用して）書き、ライブラリにジャストインタイムでRコードを低レベルSQLに「コンパイル」させます。

すべての変更が翻訳可能であるわけではないので、SQL Serverで採用されている別のアプローチがあります。SQLの「選択」コマンドからRコードスニペットを呼び出します。

私の経験では、HEITZが言及した1.、2.、3のアプローチは、R（data.table）からMySQLにデータを書き戻す3の代替案で拡張できます。

したがって、完全なステップはMySQL-> data.table-> MySQLです

DTをコピーしないdata.table構文を使用することを確認すると、RAMにも対応します。

一言で言えばNO。 SQLは、適切なインタープリターレイヤーがその上に配置されている場合、構造化された半構造化データおよび非構造化データでさえも記述および要約するための強力で簡潔かつ柔軟な方法です。ちなみに、sqlデータサイエンティストにとってほぼ必須のアイテムと考えられています。

SQL 以下のコア操作を実行するための簡潔で強力な方法です。

• プロジェクション（..を選択）
• フィルタリング（どこ ..）
• グループ化/フィルタリング（グループ化および所有）
• 基本的な集計（count、sum、avg ..）
• 参加する

インラインビューを使用して結果を組み合わせると、真の力が得られます。私はのいずれかを使用することを行う必要がある場合にはsqldf、pandasql、pysparkSql/ sparkSqlまたは直接RDBMS接続を。data.table（よりもはるかに良いdata.frame）またはdatatable（よりも良い）で可能な限り最も簡潔な方法で同じものを書くことは、試行されたクエリの複雑さに応じて、pandasさらに不格好、はるかに不格好、またはほぼ不可能です。

データ変更の場合：それは別の話です：一部の操作はSQLで簡単に表現できますが、そうでない操作もあります。ただし、UDFs を組み込むと、達成できる範囲が広くなります。現在のタスクには、UDF顧客の交差操作、カスタム集計、カスタムスコアリングメソッドなどを実行するための多数のが含まれています。