Как получить дату и время отдельно в двух столбцах из поля временной метки HANA unix?

Значение временной метки unix поступает в HANA через службы данных из базы данных MySQL.

Однако я могу найти дату, используя следующую инструкцию, но хотел бы знать, есть ли какие-либо встроенные функции в SAP HANA или в конструкторе служб данных, которые могут выполнять эту работу? Также есть ли способ получить время из результата, например, у нас есть TO_DATE для даты, отличной от RIGHT()?

SELECT TO_VARCHAR (ADD_SECONDS( '1970-01-01 00:00:00', "1452261405"))

и он вернется 2016-01-08 13:56:45


hana hana-sql-script
person Hashim    schedule 21.03.2017    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Вы можете использовать встроенные в HANA функции TO_DATE и TO_TIME:

SELECT TO_TIMESTAMP (ADD_SECONDS( '1970-01-01 00:00:00', '1452261405')) TIMESTAMP,
       TO_DATE (ADD_SECONDS( '1970-01-01 00:00:00', '1452261405')) DATE,
       TO_TIME (ADD_SECONDS( '1970-01-01 00:00:00', '1452261405')) TIME
from PUBLIC.DUMMY

Дает тебе:

Пт 08 янв 2016 13:56:45 GMT+0000 (UTC) 08.01.2016 13:56:45

person Christoph G    schedule 21.03.2017

arrow_upward
0
arrow_downward

Этот тип преобразования действительно подходит для реализации в определяемой пользователем функции (UDF). Что-то вроде этого может сделать ваш код более удобным для чтения:

FUNCTION "DEVDUDE"."sandpit::epoch_to_seconddate" (IN epoc_date integer ) 
    RETURNS SQL_SECONDDATE seconddate
    LANGUAGE SQLSCRIPT
    SQL SECURITY INVOKER AS
BEGIN

    SQL_SECONDDATE = ADD_SECONDS( to_seconddate('1970-01-01 00:00:00'), :epoc_date);

END;

Затем вы можете просто использовать его, как если бы это была встроенная функция:

 select "sandpit::epoch_to_seconddate"(-1452261405) from dummy;

SQL_SECONDDATE
1923-12-25 10:03:15.0

person Lars Br.    schedule 22.03.2017
comment
Спасибо, Ларс; имеет смысл использовать функцию для лучшей читабельности. Влияет ли это на производительность, когда нужно обработать миллионы записей, особенно по сравнению с подходом, упомянутым @Christoph? - person Hashim; 22.03.2017
comment
Согласитесь, для удобочитаемости действительно полезно создать и использовать скалярную UDF для SQL-выражений, которые вам нужны более одного раза. Только что проверил производительность в пробной учетной записи HCP SPS12. Для 1 миллиона строк выбор столбца to_date(...) и to_time(...) из целого числа занимает 100-150 миллисекунд с использованием промежуточной UDF, 50-75 миллисекунд с использованием только встроенных функций. Без тестирования я бы предположил, что производительность будет примерно такой же, потому что HANA каким-то образом сглаживает вызов UDF, но кто знает... Я бы все равно выбрал подход UDF, если производительность достаточно высока. - person Christoph G; 22.03.2017
comment
Кристоф правильно намекает на тестирование! Если исходная производительность имеет первостепенное значение, то невозможно обойти тестирование и измерение альтернативных решений. Но для любой нетривиальной сборки решения, в конечном счете, ремонтопригодность становится гораздо большим бременем. И найти узкие места и возможные улучшения в хорошо структурированной/модуляризованной кодовой базе намного проще, чем пытаться декодировать выполнение одного огромного оператора. - person Lars Br.; 22.03.2017