QA@IT
«回答へ戻る

200
 ログ書き込みでSELECTやUPDATEなんて無駄なことはしません。
 
 日毎のアクセス件数を取るのは集計時にやればいいのであって、素材であるログは用途を限定せず、例えば時間ごとの集計が欲しくなっても対応できるようすべて書き込みます。
-日毎

複雑なSQLを書くとスマートじゃないんですか?
なんか大きな勘違いをしている気がしますが。。。

さて、ログの記録ってことなので私だったらTreasure Dataとかを使えないか検討しますが、RDBMSを使うのであれば、ひたすらINSERTすると思います。
ログ書き込みでSELECTやUPDATEなんて無駄なことはしません。

日毎のアクセス件数を取るのは集計時にやればいいのであって、素材であるログは用途を限定せず、例えば時間ごとの集計が欲しくなっても対応できるようすべて書き込みます。

複雑なSQLを書くとスマートじゃないんですか?
なんか大きな勘違いをしている気がしますが。。。

さて、ログの記録ってことなので私だったらTreasure Dataとかを使えないか検討しますが、RDBMSを使うのであれば、ひたすらINSERTすると思います。
ログ書き込みでSELECTやUPDATEなんて無駄なことはしません。

日毎のアクセス件数を取るのは集計時にやればいいのであって、素材であるログは用途を限定せず、例えば時間ごとの集計が欲しくなっても対応できるようすべて書き込みます。

回答を投稿

複雑なSQLを書くとスマートじゃないんですか?
なんか大きな勘違いをしている気がしますが。。。

さて、ログの記録ってことなので私だったらTreasure Dataとかを使えないか検討しますが、RDBMSを使うのであれば、ひたすらINSERTすると思います。
ログ書き込みでSELECTやUPDATEなんて無駄なことはしません。

日毎のアクセス件数を取るのは集計時にやればいいのであって、素材であるログは用途を限定せず、例えば時間ごとの集計が欲しくなっても対応できるようすべて書き込みます。
日毎

複雑なSQLを書くとスマートじゃないんですか?
なんか大きな勘違いをしている気がしますが。。。

さて、ログの記録ってことなので私だったらTreasure Dataとかを使えないか検討しますが、RDBMSを使うのであれば、ひたすらINSERTすると思います。
ログ書き込みでSELECTやUPDATEなんて無駄なことはしません。

日毎のアクセス件数を取るのは集計時にやればいいのであって、素材であるログは用途を限定せず、例えば時間ごとの集計が欲しくなっても対応できるようすべて書き込みます。
日毎