Обсуждение статьи "Работа с СУБД MySQL из MQL5 (MQL4)" - страница 12
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
для него тьма всяких сторонних GUI/IDE - а сам sqlite просто чистый "движок" базы и API для встраивание его в приложения..
API там действительно для всего, включая NET. GUI поищу - глядишь понравится.)
https://www.mql5.com/ru/articles/862
Спасибо, прочитал. Там оч дельное замечание автора текущей статьи, который пришел,... и все испортил.)
Возможность использования есть и это хорошо. Другое дело что SQLite не стоит использовать для серьезных проектов. Во всяком случае я бы не рекомендовал. Сам сталкивался не раз с проблемой коллизий на ней. Скажем, если торговый робот прикреплен к различным чартам, а использует одну базу, причем обращение происходит к одной таблице общего назначения (скажем регистрация/изменение сессий, аккаунтов), то в любом случае вы получите ошибку типа "таблица заблокирована". И не важно что транзакции все завершены, курсоры все закрыты и БД открыта была в shared режиме. Эта проблема известна и разработчикам SQLite.
Как по мне, так из файловых БД с поддержкой SQL лучше MS Access. Как ни ругайте мелкомягких, но я от SQLite ушел на MS Access и вовсе не жалею. OleDB драйвер Jet 4.0 ставится даже с Win98, так что проекты работают на всех OC Windows.
Я уже писал ранее, что Access это наверное действительно самое оно, чем и пользуюсь. В крайнем случае MS SQL Server, тем более сейчас есть свободнораспространяемая версия. А MySQL слишком громоздкий, только дистрибутив сервера ~450 MB
Спасибо, прочитал. Там оч дельное замечание автора текущей статьи, который пришел,... и все испортил.)
Возможность использования есть и это хорошо. Другое дело что SQLite не стоит использовать для серьезных проектов. Во всяком случае я бы не рекомендовал. Сам сталкивался не раз с проблемой коллизий на ней. Скажем, если торговый робот прикреплен к различным чартам, а использует одну базу, причем обращение происходит к одной таблице общего назначения (скажем регистрация/изменение сессий, аккаунтов), то в любом случае вы получите ошибку типа "таблица заблокирована". И не важно что транзакции все завершены, курсоры все закрыты и БД открыта была в shared режиме. Эта проблема известна и разработчикам SQLite.
Как по мне, так из файловых БД с поддержкой SQL лучше MS Access. Как ни ругайте мелкомягких, но я от SQLite ушел на MS Access и вовсе не жалею. OleDB драйвер Jet 4.0 ставится даже с Win98, так что проекты работают на всех OC Windows.
Я уже писал ранее, что Access это наверное действительно самое оно. В крайнем случае MS SQL Server, тем более сейчас есть свободнораспространяемая версия.
MS Access один из худших вариантов. На VDS он еле шевелится. Чего не скажешь о том-же SQLite-он очень шустр. Есть проблема (но она с MySQL такая-же и вообще с любыми) - сейчас модель "один советник=один тред и плюс где-то там индикаторы, чарт и терминал", но она легко может измениться, плюс всё что в code-base не рассчитано на конкурентную работу, там подразумевается монопольное использование ресурса, нет необходимых блокировок, синхронизаций и так далее. И кстати это из раздела извращений - запускать более одного советника(даже если это экземпляры одного и того же) на реальном счёте.
А хотите надёжности с плюшками - ставьте Oracle (будете удивлены, но для нужд роботов он бесплатный) и APEX, пишите к нему коннектор..И ещё вариант - гонять данные через Web-Request к REST модели.
PS/ чего спорить - пока MQ не выкатит обобщённый коннектор к SQL все попытки корректно работать с СУБД обречены на провал. Тот самый случай когда компонент не реализуем силами комьюнити
А хотите надёжности с плюшками - ставьте Oracle (будете удивлены, но для нужд роботов он бесплатный) и APEX, пишите к нему коннектор..И ещё вариант - гонять данные через Web-Request к REST модели.
Да, я в курсе про Oracle. У меня даже валяется пара их сертификатов. К сожалению не пригодились.
Что касается Access, то не такой и медленный. Я его использовал для трансляции котировок в ТС (связь: терминал - база - ТС) . История, текущие котировки, состояния, логи и пр. в базе. И это для интрадея. К скорости БД претензий не было.
Боюсь, что при схожей постановке задачи SQLite не прокатит, по причинам, изложенным Eugeniy Lugovoy
Да, я в курсе про Oracle. У меня даже валяется пара их сертификатов. К сожалению не пригодились.
Что касается Access, то не такой и медленный. Я его использовал для трансляции котировок в ТС (связь: терминал - база - ТС) . История, текущие котировки, состояния, логи и пр. в базе. И это для интрадея. К скорости БД претензий не было.
Боюсь, что при схожей постановке задачи SQLite не прокатит, по причинам, изложенным Eugeniy Lugovoy
если не секрет, какой механизм использовался в ТС для вычитки данных с Aссess ?
ТС - стандартный C# ADO.NET. C буферами, их обновлениями и записью в базу. Терминал данные в базу пишет через (не помню) - либо ODBC, но скорее через Jet. Позже гляну, если интересно. В терминале встроенный экспорт в базу (любую, если драйвер на компе).
PS Похоже OLEDB
.
Приветствую Всех! Ребятки давно не заглядывал сюда. Тут прям жара по дискуссиям :) Разрешите объясниться :)
Пару лет назад занимался проектами в которых требования были достаточно разные (доп анализ рынка сторонним ПО, публикация на веб с сохранением истории, применение генетических алгоритмов, эмуляция торговли и т.п.), но данные целесообразно было иметь в БД. Поскольку требования были разными, то и выбор СУБД был соответственным. И в конце концов я решил под каждую СУБД написать врапперы к MT4 чтобы использовать "родные" драйверы, но не ODBC/OLEDB. Т.е. для mysql - libmysql, для oracle - OCI/Instant client, для SQLite - eго DLL с api, но вот для баз от Microsoft (Access/MS SQL) тут только вариант OLEDB остается. Все это было написано и существует до сих пор, здесь просто оформил статью для MySQL баз, поскольку для постсоветского пространства она все-таки ближе по моему субъективному мнению.
В общем, с базами данных я работал достаточно долго и плотно, и, появление,развитие и популярность SQLite меня не могла не затронуть :) Враппер я написал под v3 и в отдельном потоке все ок (т.е. когда на один чарт весить эксперт), однако при тестах на нескольких чартах я нежданчиком получал лок таблицы. Специально написал тестовые EA чтобы обновляли данные(строки) только по своему символу, т.е. таблица одна но строки разные чтобы не вызывать лока. результат - лок таблицы. И это не смотря на то, что сам враппер использует mutexы для выполнения операций, т.е. пока один update не завершится (+autocommit), то другой не начнется. проще говоря - локу возникнуть негде, кроме как внутри самой SQLite. Побегал по форумам и нашел что такая проблема действительно есть. Я переписал враппер под OLEDB (структура всех врапперов практически идентична, за исключением самих команд вызова API нужных СУБД) и проверил на MS Access... те же скрипты - никаких проблем. MS SQL - без проблем, PostgreSQL - без проблем, соединился с Oracle - тоже все ок.
И хотя было это достаточно давно, но ощущение от SQLite осталось... больше не экспериментировал. Единственная аналогичная база (файловая и компактная с SQL) мне помнится была MSSQL Compact Edition, но че-то руки не дошли до реализации в эту сторону.
В конце концов у меня два проекта осталось - один для MySQL (в т.ч. MariaDB) и один для OLEDB, который хоть и ограничивает возможности по сравнению с родными драйверами (например той же СУБД Oracle), но их вполне достаточно чтобы реализовывать production проекты. В этом плане я ценю стабильность + производительность решения, ну и плюс минимизация затрат на сопровождение. Ну а если нужен будет в дальнейшем переход к другой СУБД, то расходы тут будут минимальны - если упростить, то нужно всего лишь переписать запросы с учетом синтаксиса новой субд, а в целом логики проекта это не коснется.
Спасибо всем и Удачи!
не поленился "проверил из коробки" - не работает
Приветствую Павел,
Пожалуйста сообщите следующие сведения об окружении:
- Версия и битность операционной системы
- Версия, билд и битность терминала
- Версия MySQL
Достаточно странно что кернел не содержит функцию создания мьютекса, а libmysql функцию определения количество строк затронутых операцией...
Я постараюсь создать аналогичное окружение и проверить.
win 7 x64 - mt5 x64 последней версии (v5 b1455)
до MySQL не доходит, но не жалко
Сервер: Localhost via UNIX socket
Тип сервера: Percona Server
Версия сервера: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Версия протокола: 10
Пользователь: ***
Кодировка сервера: UTF-8 Unicode (utf8)