0

基数 10 の 10 進数を取り、小数点以下の桁数3.6 three hours and point 6 minutesを基数 60 に変換する数式の設定があります36 minutes。次に、ceiling を使用して最も近い 15 分の増分に分を切り上げ、常に切り上げ36 to 45 minutesます。次に、時間の部分と分の部分を連結し、それらの間に文字列のコロンを配置します。この sql はビューで実行されます。

ビューでは、文字列値ではなく 16 進数値として表示されます8:30 turns into 0x383A333020483A4D。ただし、選択クエリでは、正しい連結文字列形式になっています。何が起こっている?

CONCAT((((CEILING(((60 * ((agent_logins.hours_worked) % 1)) / 15)) * 15) / 60) + ((agent_logins.hours_worked) - ((agent_logins.hours_worked) % 1))) - (((CEILING(((60 * ((agent_logins.hours_worked) % 1)) / 15)) * 15) / 60) + ((agent_logins.hours_worked) - ((agent_logins.hours_worked) % 1))) % 1, ':', (((CEILING(((60 * ((agent_logins.hours_worked) % 1)) / 15)) * 15) / 60) + ((agent_logins.hours_worked) - ((agent_logins.hours_worked) % 1))) % 1 * 60) as hours_worked
4

3 に答える 3

1

以下に記載されているようにCONCAT()

引数にバイナリ文字列が含まれている場合、結果はバイナリ文字列になります。数値引数は、同等の文字列形式に変換されます。これは、MySQL5.5.3以降の非バイナリ文字列です。5.5.3より前では、これはバイナリ文字列です。これを回避して非バイナリ文字列を生成するには、次の例のように、明示的な型キャストを使用できます。

SELECT CONCAT(CAST(int_col AS CHAR), char_col);

5.5.3より前のバージョンのMySQLを使用している必要があるため、の数値引数CONCAT()はバイナリ文字列に変換されます(全体としてバイナリ文字列になります)。クライアントは、バイナリ列を16進形式で表示しています。これは妥当な動作です。

ドキュメントに記載されているように(そして@SofianeMの回答CONVERT()で示唆されているように)、またはを使用して非バイナリ文字列に明示的にキャストバックすることでこれを克服できますCAST()

しかし、なぜ単純に使用しないのSEC_TO_TIME()ですか?

SELECT SEC_TO_TIME(CEILING(4 * hours_worked) * 900)
FROM   agent_logins

sqlfiddleでそれを参照してください。

于 2012-12-13T23:43:36.013 に答える
1

その 16 進表現の最初の 4 バイトは、予想される文字列値の ASCII エンコードを表しているように見えます'8:30'。次の 4 バイトは、 を表す ASCII エンコーディングに表示され' H:M'ます。

0x38 = '8'
0x3A = ':'
0x33 = '3'
0x30 = '0'
0x20 = ' '
0x48 = 'H'
0x3A = ':'
0x4D = 'M'

これはあなたが尋ねた質問に実際には答えていませんが...

このタイプのフォーマットを行うために MySQL 組み込み関数を利用しないのはなぜですか? (考えられる説明の 1 つは、処理する必要がある「期間」の値が、MySQL データ型で許可されている制限、TIMEつまり -838:59:59 から 838:59:59 を超えていることです。)

それ以外の場合は、やや単純な式を使用して時間を最も近い 15 分の境界に丸め、それを時間:分の文字列表現としてフォーマットすることができます。

TIME_FORMAT(SEC_TO_TIME(CEILING( agent_login.hours_worked *4)*900),'%k:%i')

ここで SQL フィドル


ビューを行ソースとして使用する SELECT ステートメントが 8 文字を返す理由、SELECT によって生成される文字列が 4 文字のみである必要がある理由、またはクライアントが 16 進表現を表示することを選択する理由はまったく明らかではありません。(8 バイトはたまたま a の長さですBIGINT。)

于 2012-12-13T23:56:50.110 に答える
0

Convert(exp, type)この問題を解決します。コンバージョン

于 2012-12-13T23:23:04.720 に答える