Нужно ли добавить в MQL5 нативные функции обращения в MySQL базу данных(например)?

Новый комментарий
 
  • 14% (16)
  • 41% (47)
  • 10% (12)
  • 35% (40)
Всего проголосовало: 115
 

Сейчас можно легко хранить данные в локальных файлах, но для более гибкого и удобного оперирования большими обьемами больше подходят SQL/NoSQL базы данных.

Мы можем включить в MQL5(не MQL4) нативную библиотеку, поддерживающую протокол MySQL, а также вариант более продвинутого протокола(безопасного и шифрованного), который будет работать с нашими публичными SQL серверами.

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

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

 
Сначала проголосовал "мне все равно" . Потом почитал в инете  что такое MSQL и каковы его возможности+ коммент выше - и поменял мнение. Я за пункт 2.
 
Edic:
Сначала проголосовал "мне все равно" . Потом почитал в инете  что такое MSQL и каковы его возможности - и поменял мнение. Я за пункт 2.
Все равно, в какой то мере я думаю это относится только к тому что принесет пользу, если что то вносит вклад в развитии MT5, то почему бы не реализовать эту идею, я думаю каждый будет "ЗА" даже если он проголосует что ему все равно) 
 
Legi86:
Все равно, в какой то мере я думаю это относится только к тому что принесет пользу, если что то вносит вклад в развитии MT5, то почему бы не реализовать эту идею, я думаю каждый будет "ЗА" даже если он проголосует что ему все равно) 
Согласен. Лучше пусть будет больше возможностей. Ведь их наличие мешать не будет ни как и хуже уж точно не станет.
 

А как на счет доступа к жестко прописанным в настройкам, но своим серверам? Это было бы просто супер.
Публичные сервера будут либо платными, либо не очень вместительными, а свой сервер можно было бы грузить по полной.

В любом случае, будет прекрасная возможность безопасного обмена информацией (прогнозами/сигналами).
Так что ждем. 

 
komposter:

А как на счет доступа к жестко прописанным в настройкам, но своим серверам? Это было бы просто супер.

Если будет использоваться обычный MySQL протокол, то ваш зашитый пароль будет вытащен и декодирован очень быстро со всеми последующими радостями. Ладно если это будет только пароль на чтение.

Поэтому без решения вопросов безопасности с нашей стороны, это делать нельзя.

 
Renat:

Если будет использоваться обычный MySQL протокол, то ваш зашитый пароль будет вытащен и декодирован очень быстро со всеми последующими радостями. Ладно если это будет только пароль на чтение.

Поэтому без решения вопросов безопасности с нашей стороны, это делать нельзя.

А пароль в настройки терминала вынести (и зашифровать) не получится?

Я не очень понимаю, как это работает, поэтому доверюсь вашему опыту.

 
komposter:

А пароль в настройки терминала вынести (и зашифровать) не получится?

Внутри программы зашифровать легко, а вот в сетевом протоколе он может быть не защищен.

Достаточно проснифать трафик, чтобы вытащить пароль(или его хеш). Хеш можно сбрутить достаточно быстро.

 
Renat:

Внутри программы зашифровать легко, а вот в сетевом протоколе он может быть не защищен.

Достаточно проснифать трафик, чтобы вытащить пароль(или его хеш). Хеш можно сбрутить достаточно быстро.

 - Папа, это ты сейчас с кем разговаривал? (с) ;)

Нет, значит нет. Вам виднее.

 
Я думаю, что лучше сконцентрироваться на более важных вопросах.
12345
Новый комментарий