Обсуждение статьи "Работа с СУБД MySQL из MQL5 (MQL4)" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Его уже давно не лицензируют и не устанавливают автоматом со всем остальным офисом. Чего ему быть на каждом компе?
Спасибо, не знал. У меня 2007 стоит, там автоматом. Да и у большинства пока 2007 или даже 2003 встречается, имхо. Бум MySQL осваивать.)
Разумнее SQLite - он не требует отдельного сервера это раз, MQ имеет на него какие-то планы это два :-)
PS/ у меня на ноутбуке каждое обновление винды (Home ed. может от этого) сносит какие-то куски реестра относящиеся к MySQL Community Server - приходится запускать руками его "обновлятор" чтобы всё встало на свои места
Разумнее SQLite - он не требует отдельного сервера это раз, MQ имеет на него какие-то планы это два :-)
PS/ у меня на ноутбуке каждое обновление винды (Home ed. может от этого) сносит какие-то куски реестра относящиеся к MySQL Community Server - приходится запускать руками его "обновлятор" чтобы всё встало на свои места
Посмотрел https://sqlite.org/ Да, интересно, но все command-line, по простому, как даже в MS SQL не заглянешь. Для приложений разницы нет, а вот для домашнего пользования неудобно.
для него тьма всяких сторонних GUI/IDE - а сам sqlite просто чистый "движок" базы и API для встраивание его в приложения..
для него тьма всяких сторонних 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