파일에서 읽는 것은 히스토리에서 읽는 것과 표준 µl4 함수를 호출하는 것과 어떻게 다릅니까?
파일에 원하는 것을 넣을 수 있습니다
그리고 개통시간, 개통가격, 티켓번호...
무엇을 원하세요 :)
파일이 손실되면 어떻게 합니까? 아니면 파일을 쓰는 동안 오류가 발생하여 서버의 내용과 순서가 일치하지 않습니까? 아니면 이 파일이 없는 다른 컴퓨터에서 이동해야 합니까? 이 정보가 손실될 수 있는 옵션이 상당히 많으며 이 손실이 알고리즘적으로 제공되지 않으면 심각한 재정적 결과를 초래할 수 있습니다. 저것들. 이 모든 것이 시스템 전체의 신뢰성을 감소시킬 수 있는 새로운 링크를 추가합니다.
얼마나 많이...
러시아 연방 은행은 소련 은행 시스템의 후계자이며 소련 은행 시스템은 차르 러시아 은행의 후계자이며 중앙 은행 은행은 후계자입니다 ...
그래서 계산...
;)
아마도 그들은 다른 사람들이 그것을 믿기를 원할 것입니다. 그러나 실제로 그들은 역사도 이름도 명성도 없는 누보의 재물이다.
요점은 MT4의 다중 전문가 거래에 일반적인 이 루틴의 일부가 자동으로 수행되어 MT5의 경우가 아닌 아키텍처에 통합되었다는 것입니다. 물론 치명적이지는 않지만 모든 사람이 편안한 것은 아닙니다.
편하지도 않고 낯설지도 않다
저도요
그러나 대부분의 경우 다음과 같은 이유로 습관의 문제일 뿐입니다.
MT5에서 집계 위치 구조의 신뢰할 수 있는 계정을 구현할 수 있습니까?
혹시
로트 시스템에서 네팅 시스템으로 전환하는 동안 손실된 정보를 파일에 저장
그것은 당신의 전문가의 작업을 늦추지 않을 것입니다
------
물론 일반적으로 개발자의 의견을 듣는 것은 흥미로울 것입니다.
그들이 동시에 두 시스템의 구현에 반대하는 이유
이 구현이 배포판의 크기를 심각하게 증가시킬 것 같습니다.
그리고 그것은 전체 시스템을 느리게 합니다.
하지만 당신은 그들에게 물어야합니다
MT5에서 집계 위치 구조의 신뢰할 수 있는 계정을 구현할 수 있습니까?
혹시
로트 시스템에서 네팅 시스템으로 전환하는 동안 손실된 정보를 파일에 저장
그것은 당신의 전문가의 작업을 늦추지 않을 것입니다
문제는 구현의 복잡성이 아니라 솔루션의 신뢰성입니다. 이 방법은 이미 논의되었으며 신뢰할 수 없는 예가 제공되었습니다.
이러한 예와 "신뢰성" 자체의 개념은 소수의 사람들을 설득했다는 점에 유의해야 합니다. 당신은 정기적으로 개념을 대체합니다. "신뢰성"이라는 단어는 다른 것을 의미합니다.
빙고 - 천 번째 플루딜카!
문제는 구현의 복잡성이 아니라 솔루션의 신뢰성입니다. 이 방법은 이미 논의되었으며 신뢰할 수 없는 예가 제공되었습니다.
글쎄 말해줘 던스 (미리 전화해서 처음엔 주제 안읽고 부카프 많음)
파일에서 읽는 것은 히스토리에서 읽는 것과 표준 µl4 함수를 호출하는 것과 어떻게 다릅니까?
파일에 원하는 것을 넣을 수 있습니다
그리고 개통시간, 개통가격, 티켓번호...
무엇을 원하세요 :)
글쎄 말해줘 던스 (미리 전화해서 처음엔 주제 안읽고 부카프 많음)
파일에서 읽는 것은 히스토리에서 읽는 것과 표준 µl4 함수를 호출하는 것과 어떻게 다릅니까?
파일에 원하는 것을 넣을 수 있습니다
그리고 개통시간, 개통가격, 티켓번호...
무엇을 원하세요 :)
파일이 손실되면 어떻게 합니까? 아니면 파일을 쓰는 동안 오류가 발생하여 서버의 내용과 순서가 일치하지 않습니까? 아니면 이 파일이 없는 다른 컴퓨터에서 이동해야 합니까? 이 정보가 손실될 수 있는 옵션이 상당히 많으며 이 손실이 알고리즘적으로 제공되지 않으면 심각한 재정적 결과를 초래할 수 있습니다. 저것들. 이 모든 것이 시스템 전체의 신뢰성을 감소시킬 수 있는 새로운 링크를 추가합니다.
글쎄 말해줘 던스 (미리 전화해서 처음엔 주제 안읽고 부카프 많음)
파일에서 읽는 것은 히스토리에서 읽는 것과 표준 µl4 함수를 호출하는 것과 어떻게 다릅니까?
파일에 원하는 것을 넣을 수 있습니다
그리고 개통시간, 개통가격, 티켓번호...
무엇을 원하세요 :)
무엇이 다른지에 대한 질문과 "두 가지 회계 시스템 및 복잡성의 구현"에 대한 이전 질문.
예, 어려움은 없으며 배포 키트의 증가는 더욱 그렇습니다 ...
회계 문제는 서버 데이터베이스에 대한 가장 간단한 쿼리 평면에 있습니다.
나는 반복한다: 서버 데이터베이스, 즉 우리가 어디에서, 어느 터미널에서 들어가지 않았는지,
우리 파일이 죽든 말든 올바른 작동이 보장됩니다 ... 자체 구축과 달리 ...
일부 "사악한 해커"가 하드 드라이브에서 큰 망치를 움직인 경우
저장된 데이터가 완전히 손실되어 감압된 것으로 나타났습니다.
그러나이 경우 kirdyk가 조언하기 때문에 MT4도 당신을 구하지 않을 것입니다.
예를 들어 갑작스러운 정전과 같은 다른 경우에는
디스크의 데이터(결과적으로 파일의 데이터)가 저장됩니다.
---
그러나 일종의 장난꾸러기 프로그램(예: 다른 전문가)이
이 파일에 들어가서 실수로 데이터를 지우십시오.
그러나 여기서 질문은 터미널이 아니라 프로그래머로서 :)
실제로 한 가지 경우에만 소생 가능성 없이 파일을 죽일 수 있습니다.
일부 "사악한 해커"가 하드 드라이브에서 큰 망치를 움직인 경우
저장된 데이터가 완전히 손실되어 감압 된 것으로 나타났습니다.
그러나이 경우 kirdyk가 조언하기 때문에 MT4도 당신을 구하지 않을 것입니다.
예를 들어 갑작스러운 정전과 같은 다른 경우에는
디스크의 데이터(결과적으로 파일의 데이터)가 저장됩니다.
---
그러나 일종의 장난꾸러기 프로그램(예: 다른 전문가)이
이 파일에 들어가서 실수로 데이터를 지우십시오.
그러나 여기서 질문은 터미널이 아니라 프로그래머로서 :)
예, 파일을 죽일 필요조차 없습니다. 예를 들어 실패에 대한 일부 정보를 기록하지 않는 것으로 충분합니다.
유지 위치가 사용자에게 이전되어 추가 오류 소스가 될 수 있습니다. 이 블록을 구현할 때 순전히 논리적인 것조차도.