Данная статья рассчитана на программистов, проявившим интерес к использованию SQL в своих проектах. В статье читателям представляется функциональность SQLite, а также рассматриваются ее преимущества. Статья не требует знание функций SQLite, но минимальные знания SQL приветствуются.
그것을 사용할 가능성이 있고 그것은 좋습니다. 또 다른 한 가지는 SQLite를 심각한 프로젝트에 사용해서는 안된다는 것입니다. 어쨌든 나는 그것을 권장하지 않습니다. 나 자신도 두 번 이상 충돌 문제에 직면했습니다. 예를 들어, 거래 로봇이 다른 차트에 연결되어 있지만 동일한베이스를 사용하고 액세스가 하나의 범용 테이블 (예 : 등록 / 변경 세션, 계정)에 액세스하는 경우 어떤 경우에도 "테이블 잠김"과 같은 오류가 발생합니다. 그리고 모든 트랜잭션이 완료되고 커서가 닫히고 데이터베이스가 공유 모드에서 열렸어도 상관없습니다. 이 문제는 SQLite 개발자에게도 알려져 있습니다.
제 생각에는 MS Access는 SQL을 지원하는 파일 데이터베이스 중 최고입니다. 아무리 소심한 사람들을 꾸짖어도 저는 MS Access를 위해 SQLite를 떠났고 전혀 후회하지 않습니다. OleDB 드라이버 Jet 4.0은 Win98에서도 설치되므로 모든 OC 윈도우에서 프로젝트가 작동합니다.
저는 이미 앞서 Access가 정말 최고라고 썼는데, 이것이 제가 사용하는 것입니다. 극단적 인 경우 MS SQL Server, 특히 지금은 무료로 배포되는 버전이 있습니다. 그리고 MySQL은 너무 부피가 커서 서버 배포 만 ~ 450MB입니다.
그것을 사용할 가능성이 있고 그것은 좋습니다. 또 다른 한 가지는 SQLite를 심각한 프로젝트에 사용해서는 안된다는 것입니다. 어쨌든 나는 그것을 권장하지 않습니다. 나 자신도 두 번 이상 충돌 문제에 직면했습니다. 예를 들어, 거래 로봇이 다른 차트에 연결되어 있지만 동일한베이스를 사용하고 액세스가 하나의 범용 테이블 (예 : 등록 / 변경 세션, 계정)에 액세스하는 경우 어떤 경우에도 "테이블 잠김"과 같은 오류가 발생합니다. 그리고 모든 트랜잭션이 완료되고 커서가 닫히고 데이터베이스가 공유 모드에서 열렸어도 상관없습니다. 이 문제는 SQLite 개발자에게도 알려져 있습니다.
제 생각에는 MS Access는 SQL을 지원하는 파일 데이터베이스 중 최고입니다. 아무리 소심한 사람들을 꾸짖어도 저는 MS Access를 위해 SQLite를 떠났고 전혀 후회하지 않습니다. OleDB 드라이버 Jet 4.0은 Win98에서도 설치되므로 모든 OC 윈도우에서 프로젝트가 작동합니다.
앞서 Access가 정말 최고라고 이미 썼습니다. 극단적 인 경우 MS SQL Server, 특히 지금은 무료로 배포되는 버전이 있습니다.
MS Access는 최악의 옵션 중 하나입니다. VDS에서는 거의 움직이지 않습니다. 동일한 SQLite에 대해 말할 수없는 것은 매우 빠릅니다. 이제 모델은 "하나의 전문가 고문 = 하나의 거래와 어딘가에 지표, 차트 및 터미널이있는 것"이지만 쉽게 변경할 수 있으며 코드베이스의 모든 것이 경쟁 작업을 위해 설계되지 않았으며 자원의 독점 사용을 의미하며 필요한 차단, 동기화 등이 없습니다. 그리고 그건 그렇고, 실제 계정에서 둘 이상의 전문가 고문 (동일한 인스턴스 인 경우에도)을 실행하는 것은 변태 섹션에서 나온 것입니다.
그리고 플러쉬로 안정성을 원한다면 오라클 (놀랄 것이지만 로봇의 요구에 따라 무료입니다)과 APEX를 넣고 커넥터를 작성하십시오... 그리고 또 다른 옵션-웹 요청을 통해 REST 모델로 데이터를 구동하는 것입니다.
추신 / 왜 논쟁을 벌이는가 - MQ가 SQL에 대한 일반화 된 커넥터를 출시하지 않을 때까지 DBMS에서 올바르게 작동하려는 모든 시도는 실패 할 운명입니다. 커뮤니티의 힘으로 구성 요소를 실현할 수 없는 바로 그 경우입니다.
Maxim Kuznetsov: 비밀이 아니라면 TC에서 에셋에서 데이터를 읽어내는 데 어떤 메커니즘이 사용되었나요?
TC - 표준 C# ADO.NET. C 버퍼, 업데이트 및 데이터베이스에 쓰기. 터미널은 (기억이 나지 않음) ODBC를 통해 데이터베이스에 데이터를 쓰지만 Jet를 통해 데이터를 쓸 가능성이 더 큽니다. 관심이 있으시면 나중에 살펴보겠습니다. 터미널에는 데이터베이스 내보내기 기능이 내장되어 있습니다(드라이버가 컴퓨터에 있는 경우 모두).
안녕하세요, 여러분! 여러분, 오랜만에 뵙네요. 여기 토론이 정말 뜨겁네요 :) 저에 대해 설명하겠습니다 :)
몇 년 전에 저는 요구 사항이 상당히 다른 프로젝트에 참여했지만 (타사 소프트웨어에 의한 추가 시장 분석, 역사 보존을 통한 웹 게시, 유전 알고리즘 적용, 거래 에뮬레이션 등) 데이터베이스에 데이터를 보유하는 것이 편리했습니다. 요구 사항이 달랐기 때문에 DBMS의 선택도 그에 상응했습니다. 결국 저는 네이티브 드라이버를 사용하기 위해 각 DBMS에 대한 MT4 RDBMS 드라이버를 작성하기로 결정했지만 ODBC/OLEDB는 사용하지 않기로 했습니다. 즉, mysql - libmysql, 오라클 - OCI / 인스턴트 클라이언트, SQLite - API가있는 DLL이지만 Microsoft 데이터베이스 (Access / MS SQL)의 경우 OLEDB 옵션 만 있습니다. 이 모든 것이 지금까지 작성되어 지금까지 존재했으며, 여기서는 소비에트 이후 공간에 대해 여전히 주관적인 의견으로 더 가깝기 때문에 MySQL 기반에 대한 기사를 작성했습니다.
일반적으로 데이터베이스로 나는 충분히 길고 조밀하게 일했고, SQLite의 출현, 개발 및 인기는 나에게 영향을 미칠 수밖에 없었습니다 :) 나는 v3에서 랩퍼를 썼고 별도의 스레드에서 모든 것이 괜찮습니다 (즉, 하나의 차트의 무게가 EA 인 경우), 그러나 여러 차트에서 테스트 할 때 예기치 않게 테이블 잠금이 발생했습니다. 특별히 자체 기호로만 데이터 (행)를 업데이트하는 테스트 EA를 작성했습니다. 즉, 테이블은 동일하지만 행이 다르기 때문에 로케이션을 일으키지 않도록 테이블 로케이션이 발생하지 않습니다. 그리고 이것은 vrapper 자체가 뮤텍스를 사용하여 작업을 수행한다는 사실에도 불구하고, 즉 하나의 업데이트가 완료되지 않으면 (+ 자동 커밋) 다른 업데이트가 시작되지 않습니다. 간단히 말해 - loc은 SQLite 자체를 제외하고는 아무데도 발생하지 않습니다. 포럼을 검색해 보니 실제로 그런 문제가 있다는 것을 알았습니다. OLEDB에서 리퍼를 다시 작성하고 (필요한 DBMS의 API를 호출하는 명령을 제외하고 모든 리퍼의 구조는 거의 동일 함) MS Access에서 확인했습니다.... 동일한 스크립트 - 문제 없음. MS SQL-문제 없음, PostgreSQL-문제 없음, Oracle에 연결됨-또한 모두 정상입니다.
그리고 꽤 오래 전 이었지만 SQLite의 느낌은 남아있었습니다 ... 나는 더 이상 실험하지 않았습니다. 내가 기억하는 유일한 유사한 데이터베이스 (SQL이있는 파일 및 컴팩트)는 MSSQL Compact Edition 이었지만 내 손이이 방향으로 구현에 도달하지 못했습니다.
결국 두 개의 프로젝트가 남았습니다. 하나는 MySQL (MariaDB 포함)용이고 다른 하나는 OLEDB 용으로, 기본 드라이버 (예 : 동일한 DBMS Oracle)에 비해 가능성이 제한되지만 프로덕션 프로젝트를 구현하기에 충분합니다. 이 점에서 저는 솔루션의 안정성 + 성능, 그리고 유지 관리 비용의 최소화를 중요하게 생각합니다. 음, 나중에 다른 DBMS로 전환해야하는 경우 비용이 최소화됩니다. 단순화하면 새 하위 데이터베이스의 구문을 고려하여 쿼리를 다시 작성하기 만하면되며 일반적으로 프로젝트의 논리는 영향을받지 않습니다.
이를 위한 많은 타사 GUI/IDE가 있으며, sqlite 자체는 애플리케이션에 내장하기 위한 순수한 데이터베이스 엔진 및 API일 뿐입니다...
API는 실제로 NET을 포함한 모든 것을 위한 것입니다. GUI를 찾아볼게요 - 마음에 드실지도 모르겠네요).
https://www.mql5.com/ko/articles/862
감사합니다, 읽어보세요. 현재 글의 작성자가 아주 좋은 지적을 해주셨어요(..... 그리고 모든 것을 망쳤습니다).
그것을 사용할 가능성이 있고 그것은 좋습니다. 또 다른 한 가지는 SQLite를 심각한 프로젝트에 사용해서는 안된다는 것입니다. 어쨌든 나는 그것을 권장하지 않습니다. 나 자신도 두 번 이상 충돌 문제에 직면했습니다. 예를 들어, 거래 로봇이 다른 차트에 연결되어 있지만 동일한베이스를 사용하고 액세스가 하나의 범용 테이블 (예 : 등록 / 변경 세션, 계정)에 액세스하는 경우 어떤 경우에도 "테이블 잠김"과 같은 오류가 발생합니다. 그리고 모든 트랜잭션이 완료되고 커서가 닫히고 데이터베이스가 공유 모드에서 열렸어도 상관없습니다. 이 문제는 SQLite 개발자에게도 알려져 있습니다.
제 생각에는 MS Access는 SQL을 지원하는 파일 데이터베이스 중 최고입니다. 아무리 소심한 사람들을 꾸짖어도 저는 MS Access를 위해 SQLite를 떠났고 전혀 후회하지 않습니다. OleDB 드라이버 Jet 4.0은 Win98에서도 설치되므로 모든 OC 윈도우에서 프로젝트가 작동합니다.
저는 이미 앞서 Access가 정말 최고라고 썼는데, 이것이 제가 사용하는 것입니다. 극단적 인 경우 MS SQL Server, 특히 지금은 무료로 배포되는 버전이 있습니다. 그리고 MySQL은 너무 부피가 커서 서버 배포 만 ~ 450MB입니다.
고마워요, 잘 읽었습니다. 현재 글의 작성자가 아주 좋은 지적을 해주셨어요. ..... 그리고 모든 것을 망쳤습니다).
그것을 사용할 가능성이 있고 그것은 좋습니다. 또 다른 한 가지는 SQLite를 심각한 프로젝트에 사용해서는 안된다는 것입니다. 어쨌든 나는 그것을 권장하지 않습니다. 나 자신도 두 번 이상 충돌 문제에 직면했습니다. 예를 들어, 거래 로봇이 다른 차트에 연결되어 있지만 동일한베이스를 사용하고 액세스가 하나의 범용 테이블 (예 : 등록 / 변경 세션, 계정)에 액세스하는 경우 어떤 경우에도 "테이블 잠김"과 같은 오류가 발생합니다. 그리고 모든 트랜잭션이 완료되고 커서가 닫히고 데이터베이스가 공유 모드에서 열렸어도 상관없습니다. 이 문제는 SQLite 개발자에게도 알려져 있습니다.
제 생각에는 MS Access는 SQL을 지원하는 파일 데이터베이스 중 최고입니다. 아무리 소심한 사람들을 꾸짖어도 저는 MS Access를 위해 SQLite를 떠났고 전혀 후회하지 않습니다. OleDB 드라이버 Jet 4.0은 Win98에서도 설치되므로 모든 OC 윈도우에서 프로젝트가 작동합니다.
앞서 Access가 정말 최고라고 이미 썼습니다. 극단적 인 경우 MS SQL Server, 특히 지금은 무료로 배포되는 버전이 있습니다.
MS Access는 최악의 옵션 중 하나입니다. VDS에서는 거의 움직이지 않습니다. 동일한 SQLite에 대해 말할 수없는 것은 매우 빠릅니다. 이제 모델은 "하나의 전문가 고문 = 하나의 거래와 어딘가에 지표, 차트 및 터미널이있는 것"이지만 쉽게 변경할 수 있으며 코드베이스의 모든 것이 경쟁 작업을 위해 설계되지 않았으며 자원의 독점 사용을 의미하며 필요한 차단, 동기화 등이 없습니다. 그리고 그건 그렇고, 실제 계정에서 둘 이상의 전문가 고문 (동일한 인스턴스 인 경우에도)을 실행하는 것은 변태 섹션에서 나온 것입니다.
그리고 플러쉬로 안정성을 원한다면 오라클 (놀랄 것이지만 로봇의 요구에 따라 무료입니다)과 APEX를 넣고 커넥터를 작성하십시오... 그리고 또 다른 옵션-웹 요청을 통해 REST 모델로 데이터를 구동하는 것입니다.
추신 / 왜 논쟁을 벌이는가 - MQ가 SQL에 대한 일반화 된 커넥터를 출시하지 않을 때까지 DBMS에서 올바르게 작동하려는 모든 시도는 실패 할 운명입니다. 커뮤니티의 힘으로 구성 요소를 실현할 수 없는 바로 그 경우입니다.
그리고 플러스로 안정성을 원한다면 오라클 (놀랄 것이지만 로봇의 요구 사항에는 무료입니다)과 APEX를 넣고 커넥터를 작성하십시오... 그리고 또 다른 옵션은 웹 요청을 통해 데이터를 REST 모델로 구동하는 것입니다.
예, 오라클에 대해 알고 있습니다. 심지어 그들의 인증서 몇 개도 가지고 있습니다. 불행히도, 그들은 유용하지 않습니다.
Access는 그렇게 느리지 않습니다. 따옴표를 TS로 번역하는 데 사용했습니다 (연결 : 터미널-베이스-TS). 데이터베이스의 기록, 현재 따옴표, 상태, 로그 등. 그리고 이것은 인트레이드용입니다. 데이터베이스 속도에 대한 불만은 없었습니다.
Eugeniy Lugovoy가 언급 한 이유 때문에 SQLite가 비슷한 문제 진술에 대해 작동하지 않을까 두렵습니다.
네, 오라클에 대해 알고 있습니다. 심지어 몇 개의 인증서를 가지고 있기도 하죠. 안타깝게도 유용하지는 않습니다.
액세스는 그렇게 느리지 않습니다. 저는 따옴표를 TS (연결: 터미널-베이스-TS) 로 번역하는 데 사용했습니다. 데이터베이스의 기록, 현재 따옴표, 상태, 로그 등. 그리고 이것은 인트레이드용입니다. 데이터베이스 속도에 대한 불만은 없었습니다.
Eugeniy Lugovoy가 언급 한 이유 때문에 SQLite가 비슷한 문제 진술에 대해 작동하지 않을까 두렵습니다.
비밀이 아니라면 TC에서 에셋에서 데이터를 읽어내는 데 어떤 메커니즘이 사용되었나요?
TC - 표준 C# ADO.NET. C 버퍼, 업데이트 및 데이터베이스에 쓰기. 터미널은 (기억이 나지 않음) ODBC를 통해 데이터베이스에 데이터를 쓰지만 Jet를 통해 데이터를 쓸 가능성이 더 큽니다. 관심이 있으시면 나중에 살펴보겠습니다. 터미널에는 데이터베이스 내보내기 기능이 내장되어 있습니다(드라이버가 컴퓨터에 있는 경우 모두).
추신 : OLEDB
.
안녕하세요, 여러분! 여러분, 오랜만에 뵙네요. 여기 토론이 정말 뜨겁네요 :) 저에 대해 설명하겠습니다 :)
몇 년 전에 저는 요구 사항이 상당히 다른 프로젝트에 참여했지만 (타사 소프트웨어에 의한 추가 시장 분석, 역사 보존을 통한 웹 게시, 유전 알고리즘 적용, 거래 에뮬레이션 등) 데이터베이스에 데이터를 보유하는 것이 편리했습니다. 요구 사항이 달랐기 때문에 DBMS의 선택도 그에 상응했습니다. 결국 저는 네이티브 드라이버를 사용하기 위해 각 DBMS에 대한 MT4 RDBMS 드라이버를 작성하기로 결정했지만 ODBC/OLEDB는 사용하지 않기로 했습니다. 즉, mysql - libmysql, 오라클 - OCI / 인스턴트 클라이언트, SQLite - API가있는 DLL이지만 Microsoft 데이터베이스 (Access / MS SQL)의 경우 OLEDB 옵션 만 있습니다. 이 모든 것이 지금까지 작성되어 지금까지 존재했으며, 여기서는 소비에트 이후 공간에 대해 여전히 주관적인 의견으로 더 가깝기 때문에 MySQL 기반에 대한 기사를 작성했습니다.
일반적으로 데이터베이스로 나는 충분히 길고 조밀하게 일했고, SQLite의 출현, 개발 및 인기는 나에게 영향을 미칠 수밖에 없었습니다 :) 나는 v3에서 랩퍼를 썼고 별도의 스레드에서 모든 것이 괜찮습니다 (즉, 하나의 차트의 무게가 EA 인 경우), 그러나 여러 차트에서 테스트 할 때 예기치 않게 테이블 잠금이 발생했습니다. 특별히 자체 기호로만 데이터 (행)를 업데이트하는 테스트 EA를 작성했습니다. 즉, 테이블은 동일하지만 행이 다르기 때문에 로케이션을 일으키지 않도록 테이블 로케이션이 발생하지 않습니다. 그리고 이것은 vrapper 자체가 뮤텍스를 사용하여 작업을 수행한다는 사실에도 불구하고, 즉 하나의 업데이트가 완료되지 않으면 (+ 자동 커밋) 다른 업데이트가 시작되지 않습니다. 간단히 말해 - loc은 SQLite 자체를 제외하고는 아무데도 발생하지 않습니다. 포럼을 검색해 보니 실제로 그런 문제가 있다는 것을 알았습니다. OLEDB에서 리퍼를 다시 작성하고 (필요한 DBMS의 API를 호출하는 명령을 제외하고 모든 리퍼의 구조는 거의 동일 함) MS Access에서 확인했습니다.... 동일한 스크립트 - 문제 없음. MS SQL-문제 없음, PostgreSQL-문제 없음, Oracle에 연결됨-또한 모두 정상입니다.
그리고 꽤 오래 전 이었지만 SQLite의 느낌은 남아있었습니다 ... 나는 더 이상 실험하지 않았습니다. 내가 기억하는 유일한 유사한 데이터베이스 (SQL이있는 파일 및 컴팩트)는 MSSQL Compact Edition 이었지만 내 손이이 방향으로 구현에 도달하지 못했습니다.
결국 두 개의 프로젝트가 남았습니다. 하나는 MySQL (MariaDB 포함)용이고 다른 하나는 OLEDB 용으로, 기본 드라이버 (예 : 동일한 DBMS Oracle)에 비해 가능성이 제한되지만 프로덕션 프로젝트를 구현하기에 충분합니다. 이 점에서 저는 솔루션의 안정성 + 성능, 그리고 유지 관리 비용의 최소화를 중요하게 생각합니다. 음, 나중에 다른 DBMS로 전환해야하는 경우 비용이 최소화됩니다. 단순화하면 새 하위 데이터베이스의 구문을 고려하여 쿼리를 다시 작성하기 만하면되며 일반적으로 프로젝트의 논리는 영향을받지 않습니다.
모두 감사하고 행운을 빕니다!
수고를 들여 '즉시 체크아웃'을 시도했지만 작동하지 않습니다.
안녕하세요, Pavel입니다,
사용자 환경에 대한 다음 정보를 제공해 주세요:
- 운영 체제의 버전 및 비트 수
- 터미널의 버전, 빌드 및 비트 수
- MySQL 버전
커널에 뮤텍스를 생성하는 함수가 포함되어 있지 않고 libmysql에 작업의 영향을받는 행 수를 결정하는 함수가 포함되어 있지 않은 것이 매우 이상합니다...
비슷한 환경을 만들어서 확인해 보겠습니다.
WIN 7 X64 - MT5 X64 최신 버전(V5 B1455)
MySQL에 접속할 수 없지만 아쉽지는 않습니다.
서버: UNIX 소켓을 통한 로컬 호스트
서버 유형: 퍼코나 서버
서버 버전: 5.5.35-33.0-log - Percona Server(GPL), 릴리스 rel33.0, 리비전 611
프로토콜 버전: 10
사용자: ***
서버 인코딩: UTF-8 유니코드(utf8)