T-SQL указывает на хранимую процедуру OHLC

Как лучше всего преобразовать данные о тиках в OHLC, используя ввод настраиваемого временного интервала, дату начала и дату окончания, в соответствии со стандартами запросов?

Хранимая процедура должна иметь 3 параметра для передачи:

  • промежуток времени,
  • дата начала и
  • дата окончания.

Мне нужны два сценария (с хранимой процедурой для каждого): один без пропусков, когда нет записей между временным диапазоном, и второй с пропусками, когда нет записей между временным диапазоном.

Вот данные:

BigIntDateTime,    DateTime,                Ask,     Bid
20000530171000000, 2000-05-30 17:10:00.000, 0.93020, 0.93970
20000530171010000, 2000-05-30 17:10:10.000, 0.98020, 0.98970
20000530171030000, 2000-05-30 17:10:30.000, 0.92020, 0.92970
20000530171040000, 2000-05-30 17:10:40.000, 0.9020,  0.90970
20000530171336000, 2000-05-30 17:13:36.000, 0.93020, 0.93970

Временной интервал: 1 мин.

Выход для первого сценария

  • промежуток времени: 1мин
  • дата начала: 2000-05-30 17: 10: 00.000
  • дата окончания: 2000-05-30 17: 13: 36.000
Time,                    OpenAsk, HighAsk, LowAsk,  CloseAsk, OpenBid, HighBid, LowBid,  CloseBid 
2000-05-30 17:10:00.000, 0.93020, 0.98020, 0.90200, 0.90200,  0.93970, 0.98970, 0.90970, 0.90970
2000-05-30 17:13:36.000, 0.93020, 0.93020, 0.93020, 0.93020,  0.93970, 0.93970, 0.93970, 0.93970

Выход для второго сценария

  • промежуток времени: 1мин
  • дата начала: 2000-05-30 17: 10: 00.000
  • дата окончания: 2000-05-30 17: 13: 36.000
Time,                    OpenAsk, HighAsk, LowAsk,  CloseAsk, OpenBid, HighBid, LowBid,  CloseBid 
2000-05-30 17:10:00.000, 0.93020, 0.98020, 0.90200, 0.90200,  0.93970, 0.98970, 0.90970, 0.90970
2000-05-30 17:11:00.000, 0.93020, 0.98020, 0.90200, 0.90200,  0.93970, 0.98970, 0.90970, 0.90970
2000-05-30 17:12:00.000, 0.93020, 0.98020, 0.90200, 0.90200,  0.93970, 0.98970, 0.90970, 0.90970
2000-05-30 17:13:36.000, 0.93020, 0.93020, 0.93020, 0.93020,  0.93970, 0.93970, 0.93970, 0.93970

sql sql-server stored-procedures forex
person Community    schedule 09.06.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Решение

По многим причинам (отраслевая практика, производительность, повторное использование, масштабируемость, потребности ETL / интеграции и т. Д.) Лучший способ - это регулярно предварительно обрабатывать поток котировок в ‹_static_forever_> OHLC. V -таблицы для последующего повторного использования в количественных моделях, предварительно рассчитанные для всех необходимых TimeFRAME (как общепринятых в отрасли, так и синтетических).

Часть SQL для ‹aVarTimeSPAN> для обоих сценариев A и B

Затем используйте стандартный запрос SQL, чтобы SELECT только требуемую переменную, определенный пользователем период времени.

SELECT * FROM aCurrenex_AUDUSD_M1
WHERE  aUTC_BarTimeSTAMP BETWEEN <_value1_> AND <_value2_>;

.

Настраиваемая нелинейная перестановка котировок (тиков)

Scenario.A и Scenario.B по-разному изменяют кадры [Bid,Ask] записей «внутри» запрошенного промежутка времени.

Вышеуказанный образец DataSET допускает множественные интерпретации того, как должен быть рассчитан OHLC в любом из подходов сценария.

Каковы правильные значения Open / Hi / Lo / Close для реального образца, подобного этому, предполагая, что временной интервал составляет [2013.11.04-00: 00: 55.000,

YYYY.MM.DD HH:MM:SS.TTT  |Bid     |Ask
|          |             |        |
2013.11.04 00:00:53.843; 0.94582; 0.94554;
2013.11.04 00:00:59.500; 0.94575; 0.94551;
2013.11.04 00:00:59.234; 0.94582; 0.94551;
#----------|-------------|--------|-------------------------<aStandardM1BAR.EoB>
2013.11.04 00:01:02.750; 0.94582; 0.94554;
2013.11.04 00:01:02.793; 0.94582; 0.94551;
2013.11.04 00:01:08.937; 0.94582; 0.94548;
2013.11.04 00:01:09.968; 0.94580; 0.94548;
2013.11.04 00:01:11.984; 0.94573; 0.94548;
2013.11.04 00:01:12.390; 0.94573; 0.94545;
2013.11.04 00:01:12.434; 0.94573; 0.94542;
2013.11.04 00:01:34.500; 0.94581; 0.94542;
2013.11.04 00:01:38.703; 0.94581; 0.94541;
2013.11.04 00:01:38.796; 0.94573; 0.94541;
2013.11.04 00:01:42.031; 0.94572; 0.94541;
2013.11.04 00:01:47.343; 0.94582; 0.94547;
2013.11.04 00:01:48.546; 0.94582; 0.94561;
2013.11.04 00:01:48.551; 0.94575; 0.94555;
2013.11.04 00:01:50.843; 0.94570; 0.94542;
2013.11.04 00:01:50.940; 0.94570; 0.94546;
2013.11.04 00:01:51.546; 0.94568; 0.94538;
2013.11.04 00:01:51.359; 0.94570; 0.94540;
2013.11.04 00:01:55.859; 0.94570; 0.94546;
2013.11.04 00:01:55.937; 0.94563; 0.94543;
2013.11.04 00:01:57.359; 0.94564; 0.94543;
#----------|-------------|--------|-------------------------<aStandardM1BAR.EoB>
2013.11.04 00:02:05.078; 0.94563; 0.94543;
2013.11.04 00:02:06.562; 0.94564; 0.94543;
2013.11.04 00:02:08.812; 0.94572; 0.94550;
2013.11.04 00:02:15.359; 0.94572; 0.94549;
2013.11.04 00:02:15.078; 0.94572; 0.94547;
2013.11.04 00:02:32.178; 0.94563; 0.94540;
2013.11.04 00:02:32.432; 0.94564; 0.94540;
2013.11.04 00:02:33.359; 0.94564; 0.94538;
2013.11.04 00:02:34.031; 0.94564; 0.94535;
2013.11.04 00:02:39.218; 0.94564; 0.94537;
2013.11.04 00:02:41.343; 0.94559; 0.94535;
2013.11.04 00:02:46.906; 0.94559; 0.94529;
2013.11.04 00:02:46.978; 0.94559; 0.94532;
2013.11.04 00:02:51.640; 0.94559; 0.94529;
2013.11.04 00:02:55.500; 0.94560; 0.94529;
2013.11.04 00:02:56.578; 0.94582; 0.94552;
#----------|-------------|--------|-------------------------<aStandardM1BAR.EoB>
2013.11.04 00:03:01.046; 0.94582; 0.94555;
2013.11.04 00:03:03.968; 0.94585; 0.94555;
2013.11.04 00:03:04.734; 0.94583; 0.94555;
2013.11.04 00:03:09.562; 0.94581; 0.94536;
2013.11.04 00:03:10.718; 0.94568; 0.94530;
2013.11.04 00:03:10.968; 0.94561; 0.94530;
2013.11.04 00:03:11.562; 0.94566; 0.94537;
2013.11.04 00:03:13.718; 0.94568; 0.94539;
2013.11.04 00:03:14.218; 0.94568; 0.94538;
2013.11.04 00:03:14.750; 0.94569; 0.94538;
2013.11.04 00:03:15.953; 0.94569; 0.94540;
2013.11.04 00:03:16.437; 0.94570; 0.94540;
2013.11.04 00:03:21.359; 0.94575; 0.94545;
2013.11.04 00:03:23.796; 0.94573; 0.94542;
2013.11.04 00:03:29.203; 0.94570; 0.94540;
2013.11.04 00:03:29.875; 0.94567; 0.94540;
2013.11.04 00:03:34.859; 0.94572; 0.94550;
2013.11.04 00:03:36.062; 0.94574; 0.94550;
2013.11.04 00:03:36.359; 0.94574; 0.94548;
2013.11.04 00:03:36.671; 0.94574; 0.94546;
2013.11.04 00:03:36.915; 0.94575; 0.94550;
2013.11.04 00:03:37.578; 0.94578; 0.94550;
2013.11.04 00:03:37.781; 0.94576; 0.94546;
2013.11.04 00:03:37.896; 0.94573; 0.94541;
2013.11.04 00:03:38.532; 0.94571; 0.94540;
2013.11.04 00:03:39.765; 0.94570; 0.94540;
2013.11.04 00:03:39.803; 0.94568; 0.94540;
2013.11.04 00:03:58.500; 0.94573; 0.94548;
#----------|-------------|--------|-------------------------<aStandardM1BAR.EoB>
2013.11.04 00:04:08.375; 0.94575; 0.94548;
2013.11.04 00:04:09.734; 0.94580; 0.94560;
2013.11.04 00:04:14.784; 0.94592; 0.94564;
2013.11.04 00:04:14.987; 0.94587; 0.94563;
2013.11.04 00:04:14.996; 0.94587; 0.94566;
2013.11.04 00:04:15.062; 0.94574; 0.94552;
person user3666197    schedule 14.06.2014
comment
спасибо за ответ но, к сожалению, это не так - person ; 15.06.2014
comment
@Paul Какая из указанных особенностей вашего ОПРЕДЕЛЕНИЯ проблемы не была решена таким образом? TickDataSET всегда либо <static>, либо <stream_of_statics>, поэтому предварительная обработка как формата (<BigIntDateTime> - ›<Time>, включая корректировки времени смещения ZULU), так и создание / обновление статических таблиц multi-TimeFRAME с полями OHLC (+ также Volume) - это отрасль. стандарт и обязательная производительность. SELECT соответствует данному требованию для получения переменного временного интервала. Итак, Пол, в чем причина, по которой вы считаете, что ваше дело не раскрыто? - person user3666197; 15.06.2014
comment
@Paul Кстати о пробелах. Промышленность использует этот термин для баров, в которых отсутствуют какие-либо рыночные события (котировки не поступают, поскольку нет изменения PriceDOMAIN (ни Ask, ни Bid)). Таким образом, ваши обозначения пробелов немного отличаются, тем не менее, оба ваших Сценария.A и Сценария B могут быть обработаны, поскольку вы полностью контролируете задачу и <Volume> (количество поступлений котировок в течение данного TimeFRAME {M1|M5|M15|M30|H1|H4|D1|... } Bar-duration) позволяет вам обрабатывать те периоды времени, когда котировки не поступали, с SYNTH-DATA, как вы заявили для Сценария B выше. - person user3666197; 15.06.2014
comment
Я устал создавать диапазон, используя таблицу памяти в качестве помощника, но производительность недопустима. - person ; 16.06.2014
comment
@Paul Понятно. По крайней мере, SELECT делает ваши db-записи доступными для дальнейшей обработки. По многим причинам, уже упомянутым выше, механизм СУБД (к которому SQL-процесс обращается в качестве ресурса для сериализованных вычислений) является худшим местом для получения результатов. Распределенный подход, использующий подмножество записей (скорее обрабатываемых как поток, чем блок памяти (поскольку он может быть довольно толстым)), был бы моим вариантом продолжения и обработки неортогональных и нелинейных (как в TimeDOMAIN и PriceDOMAIN) OHLC + V только для начальных / конечных частей диапазона без выравнивания по полосам из QuoteSTREAM - person user3666197; 16.06.2014