1

次のデータを使用します。

date                     latitude         route      name   longitude
2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:27.718000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:01.562000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:48.765000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:34.796000  40.802338   White Loop  86  -77.85073
2009-04-11 00:49:22.468000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:35.671000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:29.125000  40.802338   White Loop  86  -77.85073
2009-04-11 00:47:19.906000  40.79889    White Loop  86  -77.85299
2009-04-11 00:47:03.609000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:54.437000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:52.687000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:51.125000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:48.578000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:41.406000  40.79889    White Loop  86  -77.85299
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:27.781000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:01.640000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:48.812000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:34.843000  40.794914   White Loop  82  -77.866844
2009-04-11 00:49:22.531000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:35.718000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:29.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:19.984000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:03.656000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:54.484000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:52.734000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:51.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:48.640000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:41.453000  40.79738    White Loop  82  -77.86755
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:27.750000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:01.593000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:48.796000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:34.812000  40.764687   White Loop  81  -77.88271
2009-04-11 00:49:22.515000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:35.703000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:29.140000  40.764687   White Loop  81  -77.88271
2009-04-11 00:47:19.937000  40.76335    White Loop  81  -77.876755
2009-04-11 00:47:03.640000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:54.468000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:52.718000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:51.156000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:48.609000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:41.437000  40.76335    White Loop  81  -77.876755

各「名前」の最新の行のみを取得するようにクエリを絞り込むにはどうすればよいですか? たとえば、私は次のようになりたいだけです。

2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552

そして、すべての結果に 1 分以内の日付値が含まれるようにします。日付値は Python の datetime プロパティであることに注意してください。

ありがとう

4

3 に答える 3

1

確かにこれはうまくいくでしょう：

query = db.GqlQuery("SELECT * FROM [table] ORDER BY date DESC LIMIT BY [num of rows]")

または、「date> 2009-04-11 00:50」のような不等式を使用すると、それ以降のすべての結果が返されます。

于 2009-06-20T22:08:16.457 に答える
1

SQL ではあらゆる種類の凝ったことを行うことができますが、Google API はかなり制限されています。

すべてのレコードを 1 分以内にしたい場合は、データベースに 1 分未満のすべてのレコードを要求し、Python で結果を照合して重複行を拒否します。

ここに表示されているデータから、「名前」ごとに 1 分あたり数行を取得しているように見えるため、そのアプローチはエレガントではありませんが十分なはずです。

別の方法は、各「名前」の最新のエントリのみを含む2番目のテーブルを保持し、そのテーブルを時々選別して、1分以上前のレコードを削除することです。

于 2009-04-16T01:31:34.417 に答える
1

私はまともな解決策を考え出したと思います。問題は私のモデルにありました：

date = db.DateTimeProperty(auto_now_add=True)

これは、そのモデルのすべてのインスタンスで、日時がすべてわずかに異なることを意味していました。これにより、データのグループ化が非常に困難になります。そのため、私の cron 関数では、すべての API リクエストのタイム スタンプがまったく同じであることを確認しました。

次の変更は、Current テーブルを作成することでした。cron が実行されるたびに、Current テーブルのすべてが削除され (1 行のみ)、新しい行が追加されます。この新しい行は、結果を半永久的に保存するログ テーブルに追加されます。

于 2009-04-16T15:28:02.313 に答える