両方のオブジェクトタイプにはそれぞれ異なる目的のための強みがあります（私はほとんどの場合、data.frameの代わりにdata.tableを使用します）。私は個人的に研究では互換的に両方を使用しますが、一般にxts形式の元の生の基礎となるデータを（xtsオブジェクトのティックまたはOHLCバーデータ）で保持します。
どちらのオブジェクトタイプは、あなたの時系列の寸法（長さや幅）が大きくない場合C.
で書かれた計算集約コードで、高速です、あなたは簡単に（例えばdata.table("index" = index(xtsobj), coredata(xtsobj)）前後に転送することができますクロスセクションタイプのモデリングに有価証券を結合する場合は、data.tablesをマージしてください。私は通常、私はあなたがカテゴリ持っている場合は制限することができ、同じタイプ（numericまたはcharacterが共通の型である）、のすべての列を使用する必要があります
xtsオブジェクトを操作する時系列のための両方のオブジェクトタイプの間で前後に切り替えます数値データと混在する変数（これを回避するためにカテゴリ変数を数値にマップすることはできますが、これは余分な作業であり、データのモデリング時の明瞭性を低下させる可能性があります）。
xtsは、特に異なる時間周波数で、合併時系列データ（merge）を作成することは非常に簡単です。また、移動ウィンドウのテクニカルインジケータをTTRとquantmodに作成するとうまく動作します。 quantmod（とadd_TA）とxtsプロットツール（?plot.xtsを参照）を利用して、燭台/ OHLCバーデータから可視化することもできます。 xtsは、ダックデータをOHLCバーデータに集約し、to.period,period.apply、endpointsなどの便利な機能を使用して、バーデータ系列の頻度を変更します（5分のバーから1時間のバーまたは毎日のバーまで） Cコードを使って実行します）。
数値にマッピングしたくない予測モデル（たとえばセキュリティカテゴリ、感情カテゴリなど）に多くのカテゴリ変数を含む予測モデル（多くの線形回帰、またはより複雑なモデル）を作成する場合は、 data.tableを使用する方が良いかもしれません。Rの多くの予測モデル（およびクラスタリングのような監督されていない方法）では、データがdata.frame形式である必要があります。その場合は、最終目標が予測モデリングである場合はdata.table/data.frame形式でデータを保存/保存/ var/urca RパッケージのVARモデルもdata.frameフォーマットを使用します。多くの予測モデル（caretなど）は、matrixという形式のデータを必要としますが、これはcoredata(xtsobj)を使用してxtsオブジェクトから簡単に抽出できます（data.frameのデータをmatrixに変換するのは一般的に簡単です）。あなたのデータセットは、（各セキュリティが大きなnのためにメモリ内の価格データのn GB単位を保持している）は本当に大きいです、そしてあなたが基（例えば、月、シンボルや月によってリターンの/ SD平均計算によって繰り返し集計を行いたい場合は
あなたはおそらくより自然なdata.tableを見つけるでしょう）、おそらくdata.tableはメモリ/ RAM内の大量のデータを扱うように設計されており、xtsの操作よりも少ないコピーをする傾向があります。