2011-08-17 14 views
1

私はさまざまなシフトからイベントを照会しようとしています。シフトは毎日午前6時、午後2時、そして午後10時に始まり、テーブル内のすべてのデータには日時タイムスタンプが付いています。以前は墓地のシフトは何も重要ではなかったので、単純なgroup by DATE(stamp)で十分でしたが、今は24時間365日です。それをシフトに分解する必要があります。グループ値のセットによって

group byという単一の句を使用して、範囲または値のセットからdatetime値を結合する方法を教えてもらえますか?難点は、各墓地の移動が2カレンダーの日に及ぶことです。

私はテーブルに24時間とシフト番号を入れた後、外部にそれを接続してgroup by DATE(stamp), HOUR(stamp)と考えていますが、それはハッキングしている可能性があり、おそらく動作していないと思われます。スーパークエリーまたはスクリプトで組み合わせる必要があります。

MySQL固有のものは完全に大丈夫ですが、これはレポートで使用したものです。

答えて

2

彼らは真夜中に開始から6時間によって相殺され、すべて8時間のシフト、あるので、あなたはにStampを回しますこのような開始のシフト時間:

select 
    stamp, 
    adddate(date(subdate(stamp, interval 6 hour)), 
     interval ((hour(subdate(stamp, interval 6 hour)) 
     div 8) * 8) + 6 hour) as shift_start 
from mytable; 

これは6時間substracts、次いで膨張し、整数除算を使用して、ダウン0 1又は2のいずれかの時間を丸めもう一度それを出してください。

は、ここではいくつかのエッジケースとテストコードです:上記のクエリの

create table mytable (stamp datetime); 
insert into mytable values ('2011-08-17 22:00:00'), ('2011-08-17 23:01:00'), 
('2011-08-18 00:02:00'), ('2011-08-18 05:59:00'), ('2011-08-18 06:00:00'), 
('2011-08-18 13:59:00'), ('2011-08-18 14:00:00'), ('2011-08-18 17:59:00'); 

出力:

+---------------------+---------------------+ 
| stamp    | shift_start   | 
+---------------------+---------------------+ 
| 2011-08-17 22:00:00 | 2011-08-17 22:00:00 | 
| 2011-08-17 23:01:00 | 2011-08-17 22:00:00 | 
| 2011-08-18 00:02:00 | 2011-08-17 22:00:00 | 
| 2011-08-18 05:59:00 | 2011-08-17 22:00:00 | 
| 2011-08-18 06:00:00 | 2011-08-18 06:00:00 | 
| 2011-08-18 13:59:00 | 2011-08-18 06:00:00 | 
| 2011-08-18 14:00:00 | 2011-08-18 14:00:00 | 
| 2011-08-18 17:59:00 | 2011-08-18 14:00:00 | 
+---------------------+---------------------+ 
+0

これはすばらしい解決策のように見え、私のテストデータではうまくいくように思えますし、その出力から日付とシフトを取得するのは非常に簡単です。私はそれを私のレポートに今統合するつもりです。本当にありがとう! – SilverbackNet

0

これを試してみてください:同じ日にすべてのあなたのシフトを維持する必要があり

GROUP BY DATE(DATE_ADD(Stamp,INTERVAL -6 HOUR)) 

0

私はあなたがアプローチ「時間とシフト番号とテーブル」あなたを追求すべきだと思います。さらに、calendar table、つまり24時間だけでなく、企業の期待されるニーズの過去、現在、未来をすべて網羅するテーブルを使用することを検討する必要があります。これはハックではありません:むしろ、それは試してテストされたアプローチです。その考え方は、SQLは宣言型のデータ駆動型ソリューションが大変役立つように、SQLはテーブル内のデータをクエリするように設計された宣言型言語であるということです。