MS Access를 MySQL 데이터베이스 백엔드의 프론트 엔드로 사용하는 문제는 무엇입니까?



Answers

이 주제가 너무 신선하지는 않지만 몇 가지 추가 설명이 있음을 압니다.

특히 더 큰 다중 사용자 데이터베이스에서 MS Access를 효과적으로 사용하려면 다음을 수행하십시오.

  • MDB를 프론트 엔드 애플리케이션과 백엔드 (데이터 전용) 파일로 분리하면 두 개의 MDB 파일이 분리됩니다.

  • 데이터 및 구조가있는 모든 테이블을 외부 데이터베이스로 마이그레이션하십시오. 그것은 다음과 같습니다 : MySQL (매우 잘 작동하고 데이터베이스 크기 제한이 없으며 MS 기술이 아니기 때문에 더 많은 기술이 필요합니다. 그러나 많은 경우에 좋은 선택입니다. 또한 더 많은 RAM과 추가 CPU로 백엔드를 확장 할 수 있습니다. 요구 사항 및 하드웨어 기능에 따라 다름). 오라클 (돈이 충분하거나 기업 라이센스가있는 경우) 또는 Oracle 10g XE (문제가되지 않는다면 데이터베이스 크기가 최대 4GB로 제한되며 항상 1GB의 RAM과 1 개의 CPU가 사용됩니다) MS SQL Server 2008 (모든 경우에 MS Access 프론트 엔드 및 MS SQL Server 백엔드를 보유하는 훌륭한 조합이지만 라이센스를 지불해야합니다! - 장점 : 밀접한 통합, 두 기술이 모두 동일한 벤더를 형성 함, MS SQL Server 동시에 효과적으로 유지하기가 쉽습니다) 또는 Express Edition (Oracle XE와 같은 이야기 - 거의 동일한 제한 사항).

  • MS Access 프론트 엔드를 백엔드 데이터베이스로 다시 링크하십시오. 백엔드 용으로 MS SQL Server를 선택한 경우 MS Access의 마법사를 사용하는 것만 큼 쉽습니다. MySQL의 경우 - ODBC 드라이버를 사용해야합니다 (간단하고 매우 효과적입니다). Oracle의 경우 - Microsoft의 ODBC 드라이버를 사용하지 마십시오. 오라클에서 제공하는 이들의 작업이 훨씬 더 효과적입니다 (Oracle ODBC 및 MS Oracle ODBC 드라이버를 통해 MS Access에서 SQL 쿼리를 실행하는 데 필요한 시간을 Oracle과 비교할 수 있습니다). 이 시점에서 견고한 데이터베이스 백엔드와 완전한 기능의 MS Access 프론트 엔드 인 MDB 파일을 갖게됩니다.

  • MDB 프론트 엔드를 MDE로 컴파일하면 많은 속도를 얻을 수 있습니다. 또한 MS Access 애플리케이션을 최종 사용자에게 배포하는 유일한 합리적인 형태입니다.

  • 일상 업무를 위해서 - MS Access 프론트 엔드에서 MDE 파일을 사용하십시오. 더 많은 미시시피 액세스 프론트 엔드 개발 MDB 파일을 사용하십시오.

  • MS Access 프론트 엔드 기능을 향상시키기 위해 잘못 작성된 ActiveX 구성 요소를 사용하지 마십시오. 자신에게 더 잘 쓰거나 적절한 것을 구입하십시오.

  • 신화에 대해 MS Access에 많은 문제가 있다는 것을 믿지 마십시오. 이것은 때로는 도움이 될 수있는 훌륭한 제품입니다. 문제는 많은 사람들이 그것이 장난감이라고 생각하거나 MS Access가 일반적으로 간단하다고 가정합니다. 일반적으로 그들은 많은 오류와 문제점을 스스로 생성하고 지식과 경험이 부족합니다. MS Access에서 성공하려면이 도구를 이해하는 것이 중요합니다. 다른 기술과 마찬가지로이 규칙이 적용됩니다.

나는 MySQL 백엔드에 앞장서는 상당히 진보 된 MS Access를 사용하고 있으며 (이 애플리케이션을 유지 보수하는 개발자로서) 매우 만족한다고 말할 수 있습니다. 내 친구, 사용자는 GUI (프론트 엔드), 속도 (MySQL)에 매우 익숙해졌으며 레코드 잠금 또는 데이터베이스 성능에 대해 아무런 문제가 없으므로 만족합니다.

또한, 좋은 습관과 다른 사람들의 경험에 대해 많이 읽는 것이 중요합니다. 나는 많은 경우에 MS Access가 좋은 해결책이라고 말할 것이다. 개인 전용 MS Access 데이터베이스 (MDB 파일)의 형태로 실험을 시작한 다음 분할 된 MS Access (MDE - 프론트 엔드, MDB - 백엔드) 및 마지막으로 MS Access 프론트 엔드로 발전한 많은 전용 사용자 정의 시스템을 알고 있습니다. (MDE) 및 "심각한"데이터베이스 백엔드 (주로 MS SQL Server 및 MySQL)가 있습니다. 또한 MS Access 솔루션을 항상 작동하는 프로토 타입으로 사용할 수 있다는 점도 중요합니다. 데이터베이스에서 백엔드를 사용할 준비가되어 있습니다 (MySQL은 가정합니다). 프론트 엔드를 원하는 기술로 다시 작성할 수 있습니다 (어쩌면 데스크탑 C # 응용 프로그램 - 당신이 필요로하는 것!).

나는 당신이 MS Access로 작업을 고려하는 데 도움이되기를 바랍니다.

감사합니다, Wawrzyn http://dcserwis.pl

Question

두 명의 사용자가 원래 하나의 MDB 파일을 통해 서로 충돌하지 않고 MS Access로 작성된 동일한 데이터베이스를 공유하려고했습니다.

필자는 Migration Toolkit (잘 작동 함)을 사용하여 간단한 MS Access 데이터베이스에서 MySQL로 테이블을 이동하고 Access를 설정하여 ODBC를 통해 테이블에 연결했습니다.

지금까지 나는 다음과 같이 실행했다.

  • 기본 키가없는 테이블에 행을 삽입 / 업데이트 / 삭제할 수 없습니다 (놀랄 일도 아닙니다).
  • MS Access의 일련 번호 필드는 기본 키 여야합니다. 그렇지 않으면 MySQL의 정수 열로 끝납니다. (natch, PK가 아닌 이유는 무엇입니까?)
  • 테이블은 MySQL의 InnoDB 테이블 유형으로 마이그레이션되었지만 액세스 관계는 MySQL 외래 키 제약 조건이되지 않았습니다.

데이터베이스를 사용하고 나면 다른 문제가 발생할 수 있습니까? 특히 두 사용자가 같은 테이블에서 작업 할 때?




일반적으로, 그것은 다릅니다 :)

애플리케이션 측에서 방금 양식을 통해 데이터를 업데이트했을 때 많은 문제가 발생하지 않았습니다. 둘 이상의 사용자가 동일한 행을 업데이트하면 경고 / 오류가 발생할 수 있습니다. 하지만 Access는 지속적으로 라이브 레코드 세트를 항상 업데이트하고있는 것으로 보입니다.

Alice가 이미 레코드 365로 작업하고 있고 Bob이이를 업데이트 한 다음 Alice가 변경 내용으로 Alice를 업데이트하려고하면 문제가 발생할 수 있습니다. 내가 기억 하듯이, Alice는 비밀스러운 오류 메시지를받습니다. 이러한 오류를 잡아 내고 적어도 사용자에게 친숙한 오류 메시지를 제공하면 사용자가 더 쉬울 것입니다.

RecordSet을 통해 VB 코드에서 레코드를 편집 할 때 특히 양식에서 동일한 데이터를 편집 할 때 더욱 많은 문제가있었습니다. 반드시 다중 사용자 문제는 아닙니다. 그러나 동일한 데이터에 대해 여러 개의 연결이있는 한 명의 사용자가 있기 때문에 거의 동일한 상황이 발생합니다.




이 질문에 직접 대답하지는 못하지만 Access 용 SQL Server 2005 마이그레이션 도구를 확인해 보는 것이 좋습니다. 필자는이 도구를 사용한 적이 없지만 SQL Server 2005 Express Edition을 사용하여 MySQL과 동일한 문제가 있는지 확인하는 것이 좋습니다.




Links