델파이를 사용하는 ADO 또는 DBX
https://stackoverflow.com/questions/1305531
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
Delphi Win32 응용 프로그램의 MS SQL, Oracle 또는 Firebird에 연결하는 데 사용하는 것이 더 낫습니다. ADO 또는 DBX (Database Express)?
둘 다 주요 데이터베이스에 연결할 수 있습니다. 나는 Ado가 연결 문자열 변경과 Ado와 드라이버가 Windows에 포함되어 있다는 사실을 좋아하므로 배치 할 추가 기능이 없다는 사실을 좋아합니다 (내가 틀렸을 때 나를 바로 잡는 것 같습니다).
DBX도 유연하며 드라이버를 내 앱으로 컴파일 할 수 있습니다.
고객의 IT 부서/선호도에 따라 데이터베이스를 변경할 수있는 능력으로 가능한 경우 단일 소스를 갖고 싶어합니다.
그러나 프로그램이 더 쉽고, 더 잘 수행되며, 메모리를 가장 효율적으로 사용합니까? 그것들을 구별 할 다른 것들이 있습니까?
고마워요, 리차드
해결책
ADO는 사용하기가 간단하고 거기에 있으므로 클라이언트 측에 CorReponding 클라이언트 드라이버를 설치해야합니다.
DBX가 더 유연하다는 것을 알았으며 IDE 및 DataSNAP와 같은 다른 기술 내에서 더 잘 통합됩니다.
당신과 같은 목적으로, 나는 제 3 자 드라이버와 DBX를 사용했습니다. Devart. 드라이버 소스를 구매하면 응용 프로그램으로 드라이버를 컴파일 할 수 있습니다.
다른 팁
델파이가 시작될 때 사람들은 델파이에서 멀티 -DBMS 지원을 칭찬했습니다. 모두가 BDE를 좋아했습니다 (이것이 유일한 방법 이었기 때문에).
그러나 지난 10 년 이상 고객을 살펴보면 응용 프로그램에서 멀티 DBMS 지원이 꾸준히 감소했습니다.
하나의 응용 프로그램에서 여러 DBM을 지원하는 비용이 높습니다.
각 DBM에 대한 지식이 있어야 할뿐만 아니라 각 DBM에는 데이터 액세스 계층에 적응 해야하는 고유 한 족장 세트가 있기 때문입니다. 여기에는 구문 및 기본 데이터 유형의 차이뿐만 아니라 최적화 전략도 포함됩니다.
또한 일부 DBM은 Ado에서 더 잘 작동하며 직접 연결이 더 좋습니다 (Oracle 클라이언트를 모두 함께 건너 뛰는 것과 같이).
마지막으로 여러 DBMS 시스템으로 소프트웨어의 모든 조합을 테스트하는 것은 매우 집중적입니다.
DBMS 백엔드 및/또는 데이터 액세스 기술을 변경 해야하는 몇 가지 프로젝트에 참여했습니다 (IE BDE에서 DBX 또는 DBX에서 직접 연결까지). 백엔드를 변경하는 것은 항상 데이터 액세스 기술을 변경하는 것보다 훨씬 더 고통 스러웠습니다. 멀티 계층 접근 방식으로 인해 다소 쉬워졌지만 자유도를 높이고 테스트 노력을 기울였습니다.
지원 멀티 -DBMS가 최종 고객이 이미 자체 DBMS 인프라를 보유하고 있으며 응용 프로그램이 이에 맞게 적응 해야하는 수직 시장 응용 프로그램에있는 일부 제품. 예를 들어 네덜란드 정부 지역에서는 Oracle이 실제로 강력했지만 SQL Server도 사용자 기반을 설정했습니다.
따라서 기능 측면뿐만 아니라 비용 측면에서도 지원하려는 DBM의 조합에 대해 생각해야합니다.
하나의 DBM을 고수하는 경우 BDE, DBX 또는 ADO와 같은 일반적인 데이터 액세스 계층을 찾는 것이 합리적이지 않습니다. 가능한 한 직접 연결을 수행 할 수 있습니다. 제 경험은 이러한 조합이 잘 작동한다는 것을 가르쳐주었습니다.
- 인터베이스 또는 파이어 버드 fibplus, anydac, 이보 또는 IBX*
- 오라클 anydac, DOA 또는 ODAC
Microsoft SQL Server와 함께 야단법석
- IBX는 Firebird를별로 좋아하지 않습니다.
이것이 델파이 애플리케이션에서 여러 DBM을 지원할 가능성과 한계에 대한 통찰력을 제공하기를 바랍니다.
-jeroen
일반 규칙 : 모든 구성 요소 계층은 추가 버그 계층을 추가 할 수 있습니다. ADO와 DBX는 모두 표준 데이터베이스 기능을 중심으로 구성 요소 래퍼이므로 모두 똑같이 강합니다. 따라서 올바른 선택은 사용하려는 데이터베이스와 같은 다른 요소를 기반으로해야합니다. MS-Access 또는 SQL Server에 연결하려면 ADO가 이러한 데이터베이스에 더 많은 기본이므로 더 나은 선택이 될 것입니다. 그러나 Firebird와 Oracle은 DBX 구성 요소의 경우 더 기본적입니다.
나는 개인적으로 Raw Ado API를 사용하는 경향이 있습니다. 그런 다음 프로젝트에서 데이터 인식 구성 요소를 사용하지 않습니다. 덜 rad입니다. 그러나 일반적으로 데이터베이스와 GUI 사이에 여러 계층이있는 클라이언트/서버 응용 프로그램을 작성하므로 상황을 더 복잡하게 만들기 때문에 종종 이런 방식으로 작업해야합니다.
내 두 센트 : DBX는 상당히 빠르며 (Oracle과 SQL 모두에서) 훨씬 더 까다 롭고 배포하기가 더 어렵습니다.
성능이 요인이라면 DBX와 함께 갈 것입니다. 그렇지 않으면, 나는 단순한 Simplicity를 위해 Ado를 사용합니다.
다른 사람들이 말했듯이, DBX는 특정한 경우 또는 특정 상황에서 원시 성능을 가질 수 있지만 ADO는 세계에서 매우 많은 수의 응용 프로그램의 기초이므로 ADO의 성능은 상대적으로 가난하지만 분명하지는 않지만 분명히는 그렇지 않습니다. "허용 할 수 없을 정도로"가난한 것을 의미합니다.
DBX의 가장 큰 "문제"는 내가 일한 주요 프로젝트에 대해 나 자신에게 정보를 제공하는 것입니다. 아무리 좋을지라도 언어/도구 회사가 제공하는 주요 인프라 기술이라는 것입니다.
이전 BDE 기술에 대한 응용 프로그램을 구축 한 사람은 해당 기술이 감가 상각되고 더 이상 지원되지 않을 때 발생하는 중단을 증언합니다. 공급자에 의한 감가 상각으로 인한 기술은 없지만 Ado는 기술 제공 업체를 넘어 업계 지원과 관련하여 분명히 우위를 점합니다.
이런 이유로 나는 이제 항상 Ado를 사용합니다. 연결 문자열을 변경하는 것만으로도 한 데이터베이스 유형에서 다른 데이터베이스 유형으로 변경할 때 걱정해야 할 유일한 것은 아닙니다. 저장된 프로 시저 통화 구문은 하나의 ADO 제공 업체마다 다를 수 있으며, 여러 다른 SQL 엔진에 배포하려는 경우 SQL 지원이 다른 곳마다 다를 수 있습니다.
이러한 문제를 완화하기 위해 ADO 객체 모델의 캡슐화를 사용합니다. 이 캡슐화는 객체 모델을 Ado와 비슷하지 않은 것으로 변모 시키려고 시도하지 않으며, 단순히 더 많은 객체 파시칼 친화적 (및 "타입"안전한) 형태 (예 : 열거 유형 및 열거 유형 및 열거 유형 및 " 수백 개의 정수 상수가 아닌 단순한 점수가 아닌 상수 및 깃발 등에 대한 세트).
내 캡슐화는 또한 이전에 언급 된 저장 프로 시저 통화 구문의 차이점과 같은 다른 제공자 행동/요구 사항의 사소한 변형 중 일부를 처리합니다.
나는 또한 다른 포스터와 비슷하게, 너무 오래 전에 사용한 "데이터 인식 제어"를 중단했다고 말해야합니다. 데이터 인식 컨트롤이 필요하거나 사용하려면 ADO를 사용하려면 ADO를 직접 사용할 수 없으며 대신 VCL 데이터 세트 모델을 통해 ADO를 노출시키는 캡슐화를 찾아야합니다.
Ado는 Microsoft World입니다
DBX는 크로스 플랫폼과 카일 릭스를 위해 처음 (델파이 6)에 만들어졌습니다.
