기고글 토론 "MetaTrader 5의 주문, 포지션 및 거래"
읽은 후이 질문에 대한 최선의 답을 찾지 못했습니다.
예를 들어 기록에서 마지막 주문 1 개만 캐시에로드하는 방법 (작업을 복잡하게하려면 마지막 주문을 기호로 표시하십시오).
예를 들어 어드바이저는 주문 빈도가 다릅니다. 하루에 30건의 주문을 할 수 있으며 며칠 또는 몇 주 동안 "침묵"할 수 있습니다.
주문을 서버에 보낸 후 티켓을 어딘가에 기억하고 티켓별로이 주문을 검색하는 변형이 있습니다. 전역 변수와 EA 로직 내부에서 모두 기억할 수 있습니다. 하지만 예를 들어 Expert Advisor가 다른 터미널에서 계좌에 연결했는데 마지막 주문의 티켓이 없는 경우 문제가 발생합니다.
HistorySelect를 통해 기록을로드해야합니다. 종료 날짜는 어느 정도 명확하지만 초기 날짜를 계산하는 방법은 무엇입니까?
작은 범위에서도 여러 주문을받을 수 있기 때문에 문제가되지 않지만 불필요한 데이터를로드하는 측면에서 최적이 아닙니다. 또는 그 중 하나가 범위에 속하지 않을 수도 있습니다.
더 작은 날짜 범위와 루프(범위를 히스토리로 이동)를 사용하여 캐시를 채울 수 있지만 작업 논리 측면에서 최적이 아닌 추가 루프, 히스토리 데이터베이스에 대한 쿼리를 수행할 수 있습니다.
제안 - 주문/거래별로 필요한 수량을 상품별로 로딩하도록 구성합니다.
그리고 더: 이 기사의 목적이 주문/거래/포지션에 액세스하는 최적의 알고리즘을 보여주는 것이라면. 최적화 측면에서 더 나아간다면, 예를 들어 티켓과 주문을 서버로 보내는 시간 만 필요한 경우이 범위의 다른 모든 데이터를이 주문 (마술, 댓글 등)에로드하는 이유를 필드별로 기록에서 캐시로로드하는 모드가 있으면 좋을 것입니다.
히스토리오더에서 *를 선택합니다. 여기서 a_date_send>@데이터스타트 및 a_date_send<@데이터엔드
DBMS 애플리케이션을 개발하는 사람들은 이러한 쿼리가 프로덕션용으로 승인되지 않을 것이라고 생각합니다. 사실, 모든 데이터가 일부 작업에 더 관여하는 상황이 있지만 이것은 규칙이 아니라 예외입니다.
읽은 후이 질문에 대한 최선의 답을 찾지 못했습니다.
예를 들어 기록에서 마지막 주문 1 개만 캐시에로드하는 방법 (작업을 복잡하게하려면 마지막 주문을 기호로 표시하십시오).
예를 들어 어드바이저는 주문 빈도가 다릅니다. 하루에 30건의 주문을 할 수 있으며 며칠 또는 몇 주 동안 "침묵"할 수 있습니다.
주문을 서버에 보낸 후 티켓을 어딘가에 기억하고 티켓별로이 주문을 검색하는 변형이 있습니다. 전역 변수와 EA 로직 내부에서 모두 기억할 수 있습니다. 하지만 예를 들어 Expert Advisor가 다른 터미널에서 계좌에 연결했는데 마지막 주문의 티켓이 없는 경우 문제가 발생합니다.
HistorySelect를 통해 기록을로드해야합니다. 종료 날짜는 어느 정도 명확하지만 초기 날짜를 계산하는 방법은 무엇입니까?
작은 범위에서도 여러 주문을받을 수 있기 때문에 문제가되지 않지만 불필요한 데이터를로드하는 측면에서 최적이 아닙니다. 또는 그 중 하나가 범위에 속하지 않을 수도 있습니다.
더 작은 날짜 범위와 루프(범위를 히스토리로 이동)를 사용하여 캐시를 채울 수 있지만 작업 논리 측면에서 최적이 아닌 추가 루프, 히스토리 데이터베이스에 대한 쿼리를 수행할 수 있습니다.
제안 - 주문/거래별로 필요한 수량을 상품별로 로딩하도록 구성합니다.
그리고 더: 이 기사의 목적이 주문/거래/포지션에 액세스하는 최적의 알고리즘을 보여주는 것이라면. 최적화 측면에서 더 나아간다면, 예를 들어 티켓과 주문을 서버로 보내는 시간 만 필요한 경우이 범위의 다른 모든 데이터를이 주문 (마술, 댓글 등)에로드하는 이유를 필드별로 기록에서 캐시로로드하는 모드가 있으면 좋을 것입니다.
히스토리오더에서 *를 선택합니다. 여기서 a_date_send>@데이터스타트 및 a_date_send<@데이터엔드
DBMS 애플리케이션을 개발하는 사람들은 이러한 쿼리가 프로덕션용으로 승인되지 않을 것이라고 생각합니다. 사실, 모든 데이터가 일부 작업에 더 관여하는 상황이 있지만 이것은 규칙이 아니라 예외입니다.
매우 큰 기록도로드하고 처리하는 데 많은 시간이 걸리지 않습니다. 또 다른 한 가지는 이러한 로딩이 모든 틱에 대해 수행되면 이미 문제가된다는 것입니다.
매우 큰 기록도 몇 초 안에 처리됩니다. 따라서 첫 번째 결론은 전체 로딩 횟수를 줄이는 것입니다.
OnInit()에서 히스토리 전체 로드를 시작하세요. 필요한 날짜를 기억하세요. 그런 다음 OnTicket()에서 "태양을 가진 집시처럼" 스토리를 돌릴 수 있습니다.
매우 큰 기록도 로드하고 처리하는 데 많은 시간이 걸리지 않습니다. 또 다른 한 가지는 이러한 로딩이 모든 틱에 대해 수행되면 이미 문제가된다는 것입니다.
매우 큰 기록도 몇 초 안에 처리됩니다. 따라서 첫 번째 결론은 전체 로딩 횟수를 줄이는 것입니다.
OnInit()에서 히스토리 전체 로드를 시작하세요. 필요한 날짜를 기억하세요. 그런 다음 OnTicket()에서 "태양을 가진 집시처럼" 스토리를 돌릴 수 있습니다.
좀 더 구체적으로 말하자면, 히스토리는 초기화 블록과 주말에만 완전히 로드되어야 합니다(주말에는 매개변수도 최적화해야 합니다).
저를 혼란스럽게 한 한 가지는 텍스트에 기록을 캐시에 신중하게 로드해야 한다는 경고가 많이 포함되어 있지만 이 작업을 구현하는 방법에 대한 실제 예가 없다는 것입니다. 이것은 솔직히 저를 화나게 했습니다:
//--- 초기 경계를 3일 전으로 설정합니다. datetime start=end-3*PeriodSeconds(PERIOD_D1);
과연 이 코드(접근 방식)가 일반 Expert Advisor에서 실제로 사용될 수 있을까요? 특정 간단한 작업 (예 : 며칠 동안 주문을 찾는 것)에 대해 이야기하지 않는 한, 예약 (이 예에서는 주말이 고려되지 않으므로 코드는 여러 거래일을 처리하는 데 적합하지 않음)이 접근 방식은 어떤 비판에도 견딜 수 없습니다.
하지만 경제적인 로딩을 구현할 수 있는 모든 도구가 있습니다. 그리고 제가 아는 한, 그러한 구현의 예가 기사에 포함되어야합니다.
예를 들어, 이 템플릿을 사용하세요:
- OnInit() - 전체 기록을 캐시에 로드하고, 전문가 자문가에게 중요한 마지막 주문(예: 메이지크 또는 상품별)을 검색하여 시간을 변수에 저장합니다.
- OnTrade() - 캐시에 로드된 기록을 업데이트하고(기억된 시간부터 시작), 마지막 주문의 시간을 업데이트합니다(새로운 유의미한 주문이 나타난 경우).
- OnTick() - 현재 로드된 캐시로 작업하거나 필요한 경우 기억된 시간부터 캐시를 로드합니다.
이 접근 방식은 이미 안정성과 보편성을 주장하고 있습니다. 게다가 리소스 활용 측면에서 "지난 3일 선택"보다 훨씬 더 경제적일 수 있습니다.
어쨌든 기사 작성해 주셔서 다시 한 번 감사드립니다. 이러한 "개발자의 사양"이 필요하지 않으면 정상적인 코드가 없을 것입니다.
이 문서에서는 하루 동안의 거래 내역을 로드하는 예제를 제공합니다(한 코드에는 3일 동안의 거래 내역을 로드하는 예제가 있습니다). 예, 이것은 제한 사항이며 예제는 보편적이지 않습니다. 그러나 독자가 기사를 읽는 동안 이러한 특성을 이해한다면, 어떤 간격으로 어떤 순간부터 거래 내역을 캐시에 로드해야 하는지 스스로 결정할 수 있을 것입니다.
독자는 가장 간단한 예제와 알고리즘을 받았으며 이제 필요한 이벤트 처리 기능에 독립적으로 적용할 수 있습니다. 독자적으로 자신만의 거래 내역 기반을 만들고 초기화 및 동기화 등을 수행할 수 있습니다.
모든 경우에 대해 최적의 거래 내역 작업을 위한 구체적인 레시피와 기능을 제공하려면 적어도 하나의 기사가 더 필요합니다. 더 정확하게는 예제 자체가 아니라 특정 작업을 해결하기 위한 접근 방식입니다. 이 기사는 거래 기능이 작동하는 방식과 연구에 시간을 낭비하지 않도록 어떤 뉘앙스에주의를 기울여야하는지 이해하는 데 목적이 있습니다.
이 기사를 읽고 나면 모든 것이 간단해질 것이라고 확신합니다.
오프 라인 모드에서 터미널 작동에 대한 설명이 어딘가에 있는지 알려주시겠습니까? 문제는 차트 데이터의 업데이트 부족으로 터미널을로드 할 수 없다는 것입니다. 직장에서 테스트하고 싶었지만 (그곳에는 인터넷이 없습니다) 차트가 업데이트를 기다리고 있고 테스터에 기호가 하나도 없습니다. 기사에서는 터미널을 시작한 후 서버와의 데이터 동기화가 수행된다고 말합니다. 그러나 연결이 없으면 어떻게 될까요 (실제로는 가정되지 않습니다). 이 불행한 바퀴를 돌리지 말고 OfLine에서 작동해야한다고 터미널에 명시 적으로 알리는 것이 합리적 일 수 있습니다. 아마도 테스터의 작업에 대한 실패가 더 적을 것입니다. 공정하게 말하면 오랫동안이 문제가 없었다고 말해야하지만 사람들은 포럼에서 이에 대해 불평합니다. 상황을 해결하기위한 몇 가지 트릭 (음, 제거 할 파일이 있음)이있을 수 있습니다 (시도했지만 집에서 서버에 연결할 때까지 도움이되지 않았습니다).
- www.mql5.com
터미널 카탈로그를 새 장비로 전송한 후 구성 데이터베이스의 일부(기호, 계정 설정, 거래 내역 등)는 하드와이어 키로 암호화되므로 특별히 삭제됩니다. 차트 기록은 영향을 받지 않습니다.
즉, 마이그레이션 후 터미널이 시장 환경을 조정할 수 있도록 모든 거래 계좌에 한 번 이상 연결해야 합니다. 그런 다음 비밀번호를 지우고 인터넷 연결을 끊고 오프라인에서 테스터로 작업할 수 있습니다.
아무것도 옮기거나 변경하지 않았습니다. 방금 노트북을 가지고 일하러 왔고 Expert Advisor를 테스트하고 싶었습니다. 계정이 하나 있고 당연히 로그인을 시도했지만 로그에 서버와 연결되지 않았다 고 표시됩니다. 단순한 오류일 수도 있지만 아무것도 할 수 없었습니다.
저는 아무것도 옮기거나 바꾸지 않았습니다. 방금 노트북을 가지고 출근해서 EA를 테스트하고 싶었습니다. 계정이 하나 있고 당연히 로그인을 시도했지만 로그에 서버와 연결되지 않았다고 표시됩니다. 무작위적인 실패일 수도 있지만 아무것도 할 수 없었습니다.
모든 마켓 워치, 차트 및 테스터 영역을 포함한 전체 터미널 창의 전체 스크린샷을 제공해 주세요.
집에서 계정에 연결하여 데이터를 완전히 펌핑하고 하나 이상의 테스트를 실행해 보세요. 그런 다음 인터넷 연결을 끊고 터미널을 다시 시작한 후 다시 시도하세요.
모든 마켓 워치, 차트 및 테스터 영역을 포함한 전체 터미널 창의 전체 스크린샷을 제공해 주세요.
집에서 계정에 연결하여 데이터를 완전히 다운로드하고 테스트를 한 번 이상 실행해 보세요. 그런 다음 인터넷 연결을 끊고 터미널을 다시 시작한 후 다시 시도하세요.
모든 것이 이전과 같이 작동하므로 아무것도 필요하지 않습니다. 분명히 우발적 인 실패였습니다. 이전에는 터미널이 승인을 요청했지만 이제는 승인없이 시작됩니다. 컴퓨터를 다시 시작하거나 다시 시작하지 않고 약 10 번 확인했습니다. 모든 것이 괜찮습니다, 감사합니다.
새로운 기고글 MetaTrader 5의 주문, 포지션 및 거래 가 게재되었습니다:
강력한 거래 로봇을 만드는 것은 MetaTrader 5 거래 시스템의 메커니즘에 대한 이해 없이는 수행할 수 없습니다. 클라이언트 터미널은 거래 서버로부터 포지션, 주문 및 거래에 대한 정보를 수신합니다. MQL5를 사용하여 이 데이터를 올바르게 처리하려면 MQL5 프로그램과 클라이언트 터미널 간의 상호 작용을 잘 이해해야 합니다.
작성자: MetaQuotes