База данных на pure MQL - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Поделитесь потом, пожалуйста, опытом.
а что тут сложного? универсальной структуры и всяких там CREATE TABLE конечно не будет.
Будет бинарный файл, все поля записи - строковые, размер каждого поля и следовательно каждой записи - фиксированный и определен заранее по тем данным, которые будут туда записываться. это позволит вычислить смещение нужной для обработки записи арифметически. соответственно прочитать или обновить одно поле - это будет чтение\запись только этого поля, а не полный перескан csv-файла.
В принципе можно будет эмулировать CREATE TABLE работой с разными файлами: на каждую таблицу - свой файл.
Для небольших баз - можно будет просто считывать все данные из файла в масиивы в памяти, и там их обрабатывать, периодически обновляя файл на диске. Почему нужен файл на диске? потому что данными будет пользоваться не только этот индикатор.
Будет бинарный файл, все поля записи - строковые, размер каждого поля и следовательно каждой записи - фиксированный и определен заранее по тем данным, которые будут туда записываться. это позволит вычислить смещение нужной для обработки записи арифметически. соответственно обновить одно поле - это будет запись только этого поля, а не полный перескан csv-файла.
Физически, все равно будет полный перескан и полная перезапись файла, т.е. замена старого файла новым. На мой взгляд, тут Вы ничего не выиграете.
Может быть сойдет за идею...
Делаем DLL, при загрузке у нее есть HMODULE, которое дает путь к DLL.
Так, что можно сделать лишний LoadLibrary.
В итоге до завершения работы МТ она никуда не выйдет.
(т.е. можно перезапускать индикаторы- DLL не выгрузится).
В DLL- простой интерфейс для работы со значениями.
На выбор- по индексам или через std::map.
Физически, все равно будет полный перескан и полная перезапись файла, т.е. замена старого файла новым. На мой взгляд, тут Вы ничего не выиграете.
Очевидно вы не поняли. Попробую подробнее.
база состоит из записей одинаковой длинны. в каждой записи - одинаковое количество полей. каждое поле имеет свою длину и эта длина тоже одинаковая во всех записях (короткие строки дополняются справа до заполнения длинны пробелами или другим символом.
Что мы получаем при таком "раскладе" на примере формирования нестандартного бара? допустим у меня стандартный набор полей DT,O,H,L,C,V. цена закрытия последнего бара плавает вслед за ценой. мне ее нужно писать "внутрь" файла, в последнюю запись ну и объемы приплюсовывать. Определив (один раз) длину файла и разделив ее на длину записи я получаю количество записей и "шаг" для расчета начала каждой записи. Найдя начало последней записи, я приплюсовываю длины полей DT,O,H,L получаю смещение в файле где начинается поле С. после этого записываю по этому смещению десяток байт цифры Close. Так что никакого перескана и прочих задержек.
Поиск тоже решается элементарно: я считываю в массив поисковое поле. Заполняю паралельный массив началами (смещения в файле) этих поле в файле или номерами записей. Дальше если мне нужно найти какоето значение я быстренько бегаю по массиву (никакого рескана!) нахожу нужное мне значение, из паралельного массива достаю смещение или номер записи, по ним рассчитываю смещение и сразуже пишу или читаю еще немножко байт.
вобщем то классическая реализация БД ;)