Примеры: Интеграция MetaTrader 4 с MS SQL-сервером

 

New article Интеграция MetaTrader 4 с MS SQL-сервером has been published:

В статье показан пример интеграции клиентского терминала MetaTrader 4 и сервером MS SQL посредством использования dll. Приложены как исходные коды на С++ и MQL4, так и готовый скомпилированный проект Visual C++ 6.0 SP5.

Использование интеграции с другими продуктами открывает дополнительные возможности в трейдинге.

Вы можете собирать тики и передавать их в MS SQL SERVER для дальнейшего анализа. Имея большую историю тиков, можно собрать любой период начиная от самого минимального кванта времени до самого нестандартного периода. Имея реальные тиковые котировки, желающие могут отлаживать стратегии зависимые от тиковых данных - известные как пипсовщики.

Можно использовать хранилище для быстрого анализа данных из других приложений, например, EXCEL, и других сторонних программных продуктов или собственных.

К примеру, можно выгрузить всю историю из History Center терминала в MS SQL, и не хранить историю в MT4, тем самым разгрузив терминал от хранения большой истории.

Вы можете выполнять расчеты нейросети, используя хранимые котировки в MS SQL SERVER: к примеру STATISTICA - 7,8 позволяют загружать котировки из SQL, можно решить в реальном времени, передавая сигналы сети в MT4.

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

Author: Yuriy Zaytsev

 

Юрий не мог бы ты ответить на  вопрос о твоей разработке.

Предусматривает ли предложенная тобой разработка тестирование в МТ4 эксперта построенного на совмесном использовании МТ4 и сторонней программы связанной посредством педложенной тобой программы.

 

Тестирование произвольного эксперта сторонней программной системой, на мой взгляд, без наличия его .mq4 исходника, невозможно в данный момент как миниум по одной причине - для тестов нужно все входные параметры эксперта, включая их атрибуты (значение, старт, шаг, стоп) занести в базу этой самой программной системы. MQL4 не позволяет легальными средствами взять из .ex4 файла эти данные. Если у вас есть исходники эксперта, то говорить о создании системы, способной запустить терминалы с экспертом на тестирование и оптимизацию, смысл есть. Вопрос, по какой логике запускать, если параметров, например, 12? Все 12 разом на оптимизацию, или перебирать в оптимизацию парами по 2 параметра, фиксируя значения остальных, или по 3 и и.д.? Здесь поле выбора логики тестирования настолько широко, сколько дистрибутивов Linux в природе, даже на порядки больше.

P.S: кстати, под MDAC 7 и 8 в статье подразумевались MDAC 2.7 и 2.8? На Windows XP стоит MDAC 2.7 SP1, т.е. обновлять его не нужно, обновление MDAC актуально для Windows 2000 (MDAC 2.5) и ниже. Последний отдельный дистрибутив MDAC - версии 2.8 SP1.

 
chv:

Тестирование произвольного эксперта сторонней программной системой, на мой взгляд, без наличия его .mq4 исходника, невозможно в данный момент как миниум по одной причине - для тестов нужно все входные параметры эксперта, включая их атрибуты (значение, старт, шаг, стоп) занести в базу этой самой программной системы. MQL4 не позволяет легальными средствами взять из .ex4 файла эти данные. Если у вас есть исходники эксперта, то говорить о создании системы, способной запустить терминалы с экспертом на тестирование и оптимизацию, смысл есть. Вопрос, по какой логике запускать, если параметров, например, 12? Все 12 разом на оптимизацию, или перебирать в оптимизацию парами по 2 параметра, фиксируя значения остальных, или по 3 и и.д.? Здесь поле выбора логики тестирования настолько широко, сколько дистрибутивов Linux в природе, даже на порядки больше.

P.S: кстати, под MDAC 7 и 8 в статье подразумевались MDAC 2.7 и 2.8? На Windows XP стоит MDAC 2.7 SP1, т.е. обновлять его не нужно, обновление MDAC актуально для Windows 2000 (MDAC 2.5) и ниже. Последний отдельный дистрибутив MDAC - версии 2.8 SP1.

 

в файле эксперта есть только названия внешних переменных и их дефолтовые значения, а аттрибуты типа "(значение, старт, шаг, стоп)" сохраняются в отдельном файле... Насчет логики оптимизации, так это ясно дело ручками выбирать надо в зависимости от логики эксперта, иначе в тупик, имхо. з.ы. сам сейчас в этом направлении гуляю... столько инфы, идей, возможностей и т.п., а времени мало....
 
embezz:
1. в файле эксперта есть только названия внешних переменных и их дефолтовые значения, а аттрибуты типа "(значение, старт, шаг, стоп)" сохраняются в отдельном файле...
2. Насчет логики оптимизации, так это ясно дело ручками выбирать надо в зависимости от логики эксперта, иначе в тупик, имхо. з.ы. сам сейчас в этом направлении гуляю... столько инфы, идей, возможностей и т.п., а времени мало....

1. Согласен полностью, комплект эксперта должен состоять из .mq4 (исходник эксперта), и плюс .set (значения его входных параметров) файлов. При этом .mq4 можно заменить на бинарный .ex4, если не требуется изменение эксперта для интеграции во внешнюю систему тестирования, что вряд ли.

2. Так выбирать из чего? Вариантов логики оптимизаций - бесконечное множество.

 
lovova:

Юрий не мог бы ты ответить на  вопрос о твоей разработке.

Предусматривает ли предложенная тобой разработка тестирование в МТ4 эксперта построенного на совмесном использовании МТ4 и сторонней программы связанной посредством педложенной тобой программы.

Это всего лишь пример связки MT4 с MS SQL4

просто показан пример показывающий возможности передачи и получения данных  в/из MS SQL

и порой на это уходит время...

т е это только технология...  доступа к данным , увязка   с конкретным применением это уже другая тема
 
chv:


P.S: кстати, под MDAC 7 и 8 в статье подразумевались MDAC 2.7 и 2.8? На Windows XP стоит MDAC 2.7 SP1, т.е. обновлять его не нужно, обновление MDAC актуально для Windows 2000 (MDAC 2.5) и ниже. Последний отдельный дистрибутив MDAC - версии 2.8 SP1.

 

  я не пробовал 2.5 не факт, но возможно и он работать будет... хотя как правило у большинства стоит 2.7

  VC++ пробовал так же без SP5 ... DLL создается нормально - проблем нет...

 
Юрий, мне кажется, реализация подобных возможностей через SQL сервер немного тяжеловесна. Работу с локальной базой можно поручить СУБД FoxPro, через ту же DLLку. FoxPro, имея "на борту" полноценную поддержку SQL, является более комфортной средой для обработки данных и не требует MDAC. Кроме того, FoxPro отличает высочайшая (если не прав - опровергните) скорость обработки больших массивов данных в составе собственных баз. SQL сервер - это все же больше хранитель (и изменятель) данных, нежели обработчик...
 
muallch:
Юрий, мне кажется, реализация подобных возможностей через SQL сервер немного тяжеловесна. Работу с локальной базой можно поручить СУБД FoxPro, через ту же DLLку. FoxPro, имея "на борту" полноценную поддержку SQL, является более комфортной средой для обработки данных и не требует MDAC. Кроме того, FoxPro отличает высочайшая (если не прав - опровергните) скорость обработки больших массивов данных в составе собственных баз. SQL сервер - это все же больше хранитель (и изменятель) данных, нежели обработчик...


:) ;) Visual Foxpro, как я припоминаю, видев его последний раз в 98-99г, это среда разработки. Хранит она данные в .dbf файлах, т.е. в файл-серверной СУБД, и этим всё сказано (MS SQL - это клиент-серверная реляционная СУБД) - по сети будут идти все таблицы целиком вместо нужного набора данных, многопользовательские блокировки, транзакции с разными уровнями изоляции, оптимизация плана исполнения запроса, views, UDF, stored procedures, безопасность, защита файлов БД от физического доступа пользователей и подобные вещи файл-серверу неизвестны или становятся непосильными при превышении объёма данных или числа клиентов базы.

Что касается объёма данных при дотестировании - у меня дома тестовая база системы дотестирования эксперта занимает 12 Гб, у клиента рабочая база ~50 Гб на MS SQL 2005 SP2 (9.00.3239). Число записей в одной только таблице превышает 100 млн. Это тестируется в LAN с выделенным WinServer2003+MSSQL2005 сервером и несколькими клиентами для запуска терминалов. Думаю, на таких объёмах любая файловая СУБД ляжет гораздо раньше их достижения.

Берите сразу MS SQL или Oracle (что знаете), с другими СУБД даже не стоит начинать городить огород. Даже бесплатная редакция MS SQL 2005 Express Edition может работать с базой до 4 Гб на одном CPU. Developer редакция вообще технически равна по возможностям Enterprise редакции.

И по поводу обработчика - в MS SQL 2005 встроена поддержка .Net CLR кода - вы можете писать свои серверные сборки (assembly) на любом .NET CLR языке (C#, VB.Net и пр.), которые будут работать в контексте SQL сервера. Например, свои суперфункции анализа или обработки данных, сложные в реализации в рамках T-SQL.

 
Согласен J)...
 
muallch:
Юрий, мне кажется, реализация подобных возможностей через SQL сервер немного тяжеловесна. Работу с локальной базой можно поручить СУБД FoxPro, через ту же DLLку. FoxPro, имея "на борту" полноценную поддержку SQL, является более комфортной средой для обработки данных и не требует MDAC. Кроме того, FoxPro отличает высочайшая (если не прав - опровергните) скорость обработки больших массивов данных в составе собственных баз. SQL сервер - это все же больше хранитель (и изменятель) данных, нежели обработчик...

SQL разумеется больше хранитель... и "извлекатель" данных


Скорость локальных данных разумеется в разы выше любого SQL но до определенного объема

VFP это самая быстрая настольная субд...  из общеизвестных ( не беру в расчет какие то экзотические проекты )


например ворочать миллионами записей VFP  увы уже не сможет так же эффективно , к тому же  имея ограничение на размер файла DBF в 2 гига


к примеру пока идет поиск данных для нейро сети наверняка прийдется вначале перерыть большой объем прежде чем найти тот объем

и те данные которые  минимально  нужны ( я имею ввиду в данном случае исследования)


в VFP нет полноценного SQL ,  то что там реализовано скорее можно назвать псевдо SQL. хотя он неплохо реализован

интеграцию с VFP конечно можно сделать...

вопрос ведь в том насколько много данных необходимо  гонять в базе

если по оценке объем во много раз меньше  2 гигабайт то скорость обработки VFP на локале конечно выше...


но согласитесь если вдруг Вам надо удаленно использовать хранилище - например для

хранения и формирования сигналов и раздаче их клиентам через удобный инструмент ,то SQL подойдет лучше чем  VFP


к примеру  движки сайтов не делают на VFP .. каждому инструменту свое


--- интеграция выполненная через MDAC вполне можно поменять на чистый ODBC

просто MDAC показался более простым решением... все же возится с SQL из C++ на ODBC чуточку сложней

---

Но на VFP я часто работаю с данными поднятыми из MT...

по крайней мере база котировок по инструменту пока вмещается

---

берем ТОЛЬКО минутку CSV к примеру GBPJPY ...  файл   СSV будет 150мег поскольку DBF это все же текст

то эти же 150 метров попадут в DBF  очевидно что VFP потянет до 6 пар  и не более в одном файле

что в общем то уже может оказаться не очень удобным

в MS SQL я могу в одну таблицу спокойно уложить все пары из HISTORY центра

и манипулировать одной таблицей проще чем писать кучу кода

---

SQL выиграет в плане масштабного сопровождения, к примеру гораздо проще поменять процедуру чем компилировать код VFP

в случае каких либо изменений...

---

     пока отвечал ВАМ боле качественно ответили по разнице между фаловыми базами и SQL ,  когда все упрется в объемы о чем я писал

     прийдется уходить на SQL

     Но если работать в пределах локала и с набором до 1 - 1.5 гиг   VFP сделает по скорости любой SQL

     Как только Вы пойдете на вырост по данным или появится необходимость в какой либо удаленной работе, VFP умрет...

---