lobotomi's

출처: http://blog.naver.com/PostView.nhn?blogId=hongjig&logNo=150079382193

김형훈 asinayo73@hotmail.com

애플의 아이폰이 시장에 출시되면서, 많은 사람들이 모바일 컴퓨팅 기기에 관심을 가지게 되었다. 기존의 모바일 통신기기가 단순한 음성/영상 통신기기에서 멀티미디어를 비롯한 다양한 기능을 지원하는 대용량 기반의 모바일 컴퓨팅 기기로 진화하게 되면서, 많은 데이터를 처리할 수 있게 되었고 이와 관련된 처리 방법이 매우 중요한 위치를 가지게 되었다. 모바일 컴퓨팅 기기에서 데이터를 어떻게 관리해야 하는지에 대해서 살펴보도록 하자.

모든 모바일기기는 하드웨어와 소프트웨어로 구성되어 있다. ARM기반의 하드웨어에서 CPU의 성능이 향상되면서 다양한 어플리케이션을 수용할 수 있게 되었다. 기존의 ARM926EJ-S부터 시작하여 현재는 Cortex A8코어가 지원됨으로써 CPU가 처리할 수 있는 속도 및 능력이 향상되었다. 90nm 공정과 공간 최적옵션을 사용했을 때 최대 250MHz의 CPU 성능을 가지는 ARM926EJ-S가 65nm 공정과 속도 최적옵션을 사용하여 650∼1100MHz의 성능을 가지는 Cortex A8 CPU로 진화됨으로써 이러한 결과를 얻게 되었다. CPU 성능과 더불어 모바일 기기에서 가장 중요한 요소인 메모리의 경우에는 소프트웨어가 실제로 실행되는 장소인 휘발성 메모리의 용량이 증가할 수록 많은 어플리케이션이 동작할 수 있게 되고, 많은 어플리케이션이 실행될 수 있는 기기에서는 데이터베이스의 활용도 및 중요도가 그만큼 높아졌다. 이와 같이 중요한 역할을 담당하는 데이터베이스는 모바일 컴퓨팅의 성능/기능을 만족시키기 위해서 사용되는 모바일 플랫폼의 기본 시스템으로서 사용된다.

DBMS 솔루션은 비즈니스모델에 따라서 상용 솔루션과 오픈 소스 기반의 솔루션으로 나눌 수 있다. 상용 데이터베이스 솔루션은 일정한 금액을 받고 이를 원하는 업체에 제공을 하기 때문에 제공 이후의 사후 관리에 대해서도 많은 지원 대책이 존재하지만, 오픈 소스 기반의 데이터베이스 솔루션의 경우에는 오픈 소스를 활용하는 주체가 실질적인 솔루션 공급자와 운용자의 두 역할을 담당해야 하기 때문에 사후 관리에 있어서도 많은 책임이 주어진다. 물롞, 많은 오픈 소스 기반의 솔루션들도 상당한 수준의 상용화 수준을 이미 가지고 있으며, 전문적으로 이를 지원하는 조직을 가지고 있는 솔루션도 있다.

오픈 소스는 많은 형태의 라이선스를 가지고 있으며, 그 중 하나인 듀얼 라이선스 비지니스 모델을 적용한 솔루션의 경우에는 오픈 소스로 개인에게 공개하는 버전과 유상으로 기업에게 제공하는 버전이 존재한다. 이러한 오픈 소스 비즈니스 모델을 적용한 대표적인 제품으로서 MySQL이 있다. 오픈 소스기반의 솔루션을 사용할 경우에는 대체적으로 최소의 비용을 투자하여 최대의 효과를 얻을 수 있다는 점에서 많은 매력이 존재하기 때문에 기존의 성숙된 시장에 보다 용이하게 진입하고자 하는 경우에 사용될 수 있다. 하지만, 오픈 소스 기반의 솔루션을 초기에 도입하는 경우에는 이러한 작업들이 쉽게 여겨질 수 있지만, 상용화하고자 하는 타겟에 최적화하여 향상시키기 위해서는 많은 부가적인 노력이 필요하다.

대표적인 오픈 소스 기반의 DBMS 솔루션으로 다음과 같은 것들이 존재한다.

. MySQL
. PostgreSQL
. SQLite
. BerkeleyDB

MySQL은 빠른 성능과 멀티 쓰레드, 멀티 유저를 지원하는 SQL(Structured Query Language) 데이터베이스 서버 솔루션이다. MySQL은 대용량 데이터 처리 기기 뿐만 아니라 임베디드 기기에도 적용이 가능한 솔루션이며, 듀얼 라이선스 정책을 사용하여 GPL(GNU General Public License) 기반으로 코드가 오픈되어 일반 사용자들도 쉽게 접귺이 가능하다. MySQL은 C와 C++를 사용하여 만들어졌으며, Windows, OpenBSD, Mac OS X, AIX, Solaris 등의 다양한 플랫폼에 적용되어 있다. MySQL이 효과적으로 사용하기 위해서 다음과 같은 조건들을 만족하면 된다. 무엇보다도 쓰레드 라이브러리가 안정적이어야 하고, 파일 시스템의 안전성이 높으면서 성능이 높아야만 한다. 또한 테이블 사이즈와 개수도 영향을 줄 수 있는데, 큰 테이블들을 가지고 있는 파일들의 수가 증가할수록 이에 대한 파일시스템의 처리능력이 낮아질 수 있다. MySQL이 SMP(Symmetric Multi-Processor)을 사용함으로써 성능을 향상시킬 수 있으며, 사용자의 수를 제한함으로써 성능을 극대화할 수도 있다. 이러한 사항들과 더불어 MySQL이 컴파일될 때 해당 플랫폼의 최적화 옵션이 사용되어야만 한다. MySQL은 트랜잭션과 비트랜잭션 저장엔진 모두를 지원하며, 인덱스 압축을 이용한 B-tree 디스크 테이블을 사용한다. 다른 추가 저장엔진의 사용이 용이한 것도 또 다른 장점이다. 그리고, 쓰레드 기반의 메모리 할당 시스템을 사용할 수 있으며, 최적화된 스윕 멀티 조인을 사용하여 빠른 조인을 수행할 수 있다. In-memory Hash 테이블을 사용하고, 최적화된 클래스 라이브러리를 사용함으로서 빠른 SQL 함수를 제공할 수 있다. 고정길이와 가변길이 변수 타입을 지원하며, Group 관련된 함수들을 지원하고, GROUP BY/ORDER BY 젃에 대한 전반적인 지원을 수행한다.

MySQL은 최대 5천만 개의 레코드를 지원하며, 20만 개의 테이블과 50억 개의 행을 지원할 수 있다. 테이블다 64개의 인덱스를 지원할 수 있으며, 각 인덱스는 1부터 16개의 칼럼들로 구성되어 있다. 최대 인덱스 길이는 1000바이트이다. MySQL 서버로 클라이얶트는 TCP/IP를 통해서 접속할 수도 있으며, 만약에 Windows NT 계열의 시스템을 사용하는 경우에는 이름 지정 파이프를 통해서도 접귺이 가능하다.

PostgreSQL는 POSTGRES v4.2에 기반한 ORDBMS(Object Relational DBMS)이다. Windows를 비롯하여 Linux, AIX, BSD, HP-UX, Mac OS X, Solaris 등의 다양한 플랫폼을 지원한다. ACID 특성을 만족하며, 외래 키, 조인, 뷰, 트리거, 저장 프로시저에 대한 지원이 이루어지고 있다. INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP 등의 SQL92와 SQL99 데이터 타입을 만족하고, 그림, 사운드, 비디오를 포함하는 바이너리 형태의 큰 오브젝트들을 지원한다. 또한, PostgreSQL은 즉시 복구, 테이블공간, 비동기 복제, 중첩된 트랜잭션, 온라인 백업을 지원한다. PostgreSQL은 처리 가능한 최대 데이터베이스 크기와 테이블당 최대 행/최대 인덱스의 수에는 제약이 없으며, 최대 테이블 크기는 32TB, 최대 행 크기는 1.6TB, 최대 필드 크기는 1GB를 지원한다. PostgreSQL는 B-tree, R-tree, Hash, GiST(Generalized Search Tree)를 이용한 인덱싱 방법을 지 원한다. GiST 인덱싱은 B-tree, B+-tree, R-tree, 부분합 tree, 랭크된 B+-tree 등을 포함하는 정렬/검색 알고리즘들을 사용할 수 있도록 만들어 놓은 시스템이다.
이 외에도 테이블 상속, 룰 시스템, 데이터베이스 이벤트와 같은 특징들을 포함하고 있다. 테이블 상속은 테이블 생성 시에 베이스 클래스가 되는 다른 테이블로부터 상속받아서 새로운 테이블을 만들 수 있다. 룰 시스템은 데이터베이스 설계자가 새로운 동작을 위한 룰을 생성할 수 있도록 한다. 데이터베이스 이벤트 기능은 LISTEN/NOTIFY 명령어들을 사용하여 클라이얶트들 사이에서 전송되는 메시지와 이벤트들이 지원되는 것을 의미한다. 트리거나 저장 프로시저를 사용할 때 발생하는 이벤트들에 대한 모니터링을 통해서 처리가 테이블의 변경상황을 알 수 있다.
PostgreSQL는 SQL 표준의 많은 부분을 지원하면서, 복합 쿼리, 외래 키, 트리거, 뷰, 트랜잭션 무결성이 지원된다. PostgreSQL는 서버/클라이얶트 모델을 사용하며, 서버 프로세스는 클라이얶트 어플리케이션과 데이터베이스를 연결할 수 있도록 하고, 데이터베이스 파일을 관리한다. 서버/클라이얶트가 서로 다른 호스트에서 존재할 경우에 TCP/IP 연결을 통해서 통신할 수 있다. 서버는 여러 개의 클라이얶트들로부터의 연결을 동시에 수락할 수 있으며, 각 연결을 위해서 새로운 처리 프로세스를 생성한다.
PostgreSQL는 BSD 라이선스를 사용하기 때문에 보다 자유로운 소스코드 관리 및 활용이 이루어질 수 있다.

SQLite는 구글의 안드로이드, 노키아의 Maemo, 애플의 iPhone에 적용된 솔루션이다. 기존의 DBMS가 엔터프라이즈급에서 사용되던 것과는 달리 이는 경량화된 특성을 바탕으로 모바일 기기에 주로 적용되었다. SQLite의 대표적인 특성으로 설정이 필요없다는 것과 서버가 없다는 점이다. SQLite는 설치하는 과정이 필요없으며 셋업하는 과정도 없다. 따라서, 시작, 정지, 설정해야 하는 서버 프로세스도 없다. 별도의 관리자가 이를 관리할 필요가 없기 때문에 사용이 간단한 장점을 가지고 있다. 더군다나, SQLite는 서버/클라이얶트 모델로 동작하는 것이 아니기 때문에 클라이얶트가 서버에 TCP/IP로 접속해서 처리하는 동작이 필요없다. 디스크에 존재하는 데이터베이스 파일을 직접 읽고 쓰기 때문에 별도의 서버동작을 위한 프로세스가 존재하지 않는다. SQLite는 단 하나의 데이터베이스 파일을 사용하기 때문에 관리가 매우 용이하다.
SQLite는 가변 길이 레코드를 지원하며, BLOB, CLOB들을 사용할 수 있도록 한다. 가변 길이 레코드를 지원함으로써 더 작은 데이터베이스 파일을 만들 수 있고, 따라서 더 빠른 동작을 이끌어 낼 수 있다.
SQLite는 온라인 백업 인터페이스를 사용하여 디스크 파일의 컨텎츠를 인-메모리 데이터베이스로 또는 그 반대 방향으로 복사함으로서 핫 백업을 지원한다. 또한 동일한 페이지와 스키마 캐시를 공유하기 위한 2개 이상의 연결을 가능하게 해 준다. 데이터베이스에서 각 페이지와 인덱스 별로 각각의 B-tree가 독립적으로 사용되며, X/Y 좌표에 대한 최소/최대 값을 가지는 공간 시스템을 다루기 위해서는 R-tree를 사용한다. 그렇지만, SQLite는 몇 가지 사항에 대해서 미지원되는 것들이 존재한다. 트리거 중에 일부 특성들이 지원되지 않으며, ALTER TABLE 중 RENAME TABLE, ADD COLUMN은 지원되지 않는다. LEFT OUTER JOIN의 경우에는 지원되지만, RIGHT OUTER JOIN이나 FULL OUTER JOIN은 지원되지 않는다. VIEW는 SQLite에서는 읽기 전용이며, VIEW에서 INSERT, DELETE, UPDATE는 불가능하다.
SQLite는 Public domain이라는 라이선스 정책을 사용하고 있기 때문에 많은 사용자들이 자유롭게 사용할 수 있으며, 코드의 수정이 이루어지더라도 반드시 이를 공개할 필요는 없다. SQLite 솔루션을 지원하기 위한 조직으로서 Hwaci(www.hwaci.com/sw/sqlite)가 있으며, SQLite의 높은 품질의 지원을 받기 위해서는 SQLite 컴소시움에 가입하면 된다. 컨소시움에 가입하기 위해서는 멤버쉽 비용을 내고 따로 관리를 받으면 되며, 심비안, 블룸버그, 어도비, 모질라가 가입되어 있다.

Berkeley DB는 라이브러리 형태로 어플리케이션으로 링크되는 Oracle에서 제공하는 오픈소스 기반의 DBMS이다. Berkeley DB는 서버/클라이얶트 구조를 사용하지 않고, SQL 처리과정을 생략함으로써 성능을 향상시켰으며, 동작 시 처리 실패에 의한 복구 및 데이터 무결성을 보장하기 위한 트랜잭션 기능을 지원한다. 관리자가 별도로 필요하지 않고 각 어플리케이션이 각각의 데이터베이스에 대한 관리 기능을 수행한다.

Berkeley DB는 데이터베이스의 동시 액세스를 지원하기 때문에 멀티 프로세서 시스템에서 멀티쓰레드 또는 멀티프로세스 어플리케이션은 최대의 효과를 얻을 수 있다. 물롞 한 개의 프로세서를 사용하는 시스템의 경우에도 이러한 효과를 얻도록 되어 있다. Berkeley DB는 설계 목적과 데이터 특성에 맞추어서 높은 쓰루풋을 낼 수 있는 시스템을 구성할 수 있는 트랜잭션 기능을 제공한다. Berkeley DB는 최대 4GB의 레코드를 가질 수 있으며, 수 TB 크기의 테이블들을 가질 수 있다. 다수의 사용자가 사용할 때의 충돌을 회피하면서, 성능을 최대화하기 위해서 MVCC(Multi-Version Concurrency Control) 또는 로깅하기 이전에 쓰기 동작을 수행하는 전형적인 방법을 사용할 수 있다.

Oracle의 Berkeley DB는 인프라스트럭쳐 시스템에서도 광범위하게 사용된다. 모바일 게이트웨이, 메시지 서비스를 위한 저장 시스템, 모바일 사업자를 위한 OSS(Operational Support Systems), BSS(Business Support Systems)와 같은 시스템들에 사용될 수 있다. 이와 더불어서 작은 풋-프린트, 높은 안정성, 제로 관리기능 및 손쉬운 적용방법을 토대로 휴대용 모바일 기기에서도 영역을 넓히고 있다. 텍스트, 이메일, 인스턴스 매시지 그리고, 각종 멀티미디어 파일 등을 저장하기 위해서 사용된다.

다양한 오픈 소스 기반의 DBMS 솔루션이 존재하기 때문에 이 중에서 어떠한 솔루션을 선택해서 과제에 적용할 것인가를 결정하는 것이 무엇보다도 중요하다. DBMS를 선택하는 방법으로 다음과 같은 9가지 사항들이 있으므로, 이를 고려하도록 한다.

1. 데이터베이스가 사용자가 원하는 다양한 기능 모두를 지원할 수 있는가?
2. 높은 가격 경쟁력을 가지고 있는가?
3. 시장이 원하는 시점에 시장이 원하는 기능을 포함하는 버전을 제공할 수 있는가?
4. 크로스 플랫폼에 포팅이 가능하며 쉽게 될 수 있는가?
5. 관리자가 용이하게 관리할 수 있는가?
6. 보다 나은 성능을 지원하는가?
7. 안정성이 충분히 보장되는가?
8. 작은 풋-프린트가 지원되는가?
9. 확장이 용이하며, 사용하기 쉽고 편리한가?

가장 최우선적으로 DBMS는 사용자가 원하는 본연의 목적을 달성해야 한다. 많은 어플리케이션이 취급해야 하는 데이터들을 최상의 조건으로 다룰 수 있어야 하며, 가장 빠르게 원하는 데이터를 원할 때 가지고 올 수 있어야만 한다. 물롞 이러한 성능을 지원한다고 해서 가격경쟁력이 없다면 이는 이러한 솔루션을 사용하는 제품에 대한 가격경쟁력을 또한 저하시키므로 고려해야만 한다. DBMS는 시스템에 있어서 데이터를 다루는 기본적인 기반 소프트웨어이다. 따라서, 매우 특정한 목적을 가지는 경우가 아니면, 어느 특정 제품에서만 사용되는 것이 아니라 광범위하게 사용될 수 있다. 따라서, 광범위하게 사용될 수 있기 위해서는 다양한 플랫폼에도 포팅이 쉽게 될 수 있어야만 한다.

이러한 9가지 고려 사항 중에서 모바일 기기에서 특히 더욱 더 큰 중요성을 가지는 것으로서 관리자가 용이하게 관리할 수 있는 지, 작은 풋-프린트가 지원되는 지와 사용하기 쉬운지의 여부이다. 모바일이라는 홖경은 한정된 자원만을 사용할 수 있으며, 여러 가지 자원의 확장이 용이하지 않다. 그렇다는 것은 DBMS가 자원을 충분히 사용하지 못할 수도 있다는 것을 의미하며, 따라서 최소한의 자원만을 사용해서 동작할 수 있어야만 한다는 의미이다. 이렇게 최소한의 자원만을 사용해서 동작하기 위해서는 별도의 관리자를 통한 제어와 다양한 설정방법이 불필요할 수 있다. 이와 같은 특성을 만족시키는 대표적인 오픈 소스 DBMS가 SQLite이다. SQLite는 실제로 Android, iPhone, Maemo와 같은 모바일 플랫폼에서 기본 DBMS로 사용되고 있다.

DBMS는 많은 수의 데이터들을 빠른 시간 안에 처리하고 쉽게 관리하기 위한 것이므로, 이러한 목적이 최우선적으로 고려되어야만 한다. 모바일 기기는 전화번호, 콜 로그, 메시지, 다이어리와 파일 매니저를 비롯한 거의 모든 어플리케이션들을 지원하므로, 이러한 어플리케이션에서 다루는 데이터들의 양이 많아 질수록 DBMS의 성능이 필수 고려사항이 된다. 데이터를 처리하는 방법에 따라서 처리하고자 하는 용량이 증가시의 처리속도가 선형 그래프 형태로 증가할 수 도 있고, 로그 그래프 형태로 증가할 수 도 있다. 따라서, 사용하고자 하는 데이터베이스 솔루션이 데이터처리 방법에 있어서 어떠한 특성을 가지는지 확인한 이후에 이에 맞추어서 사용해야 한다.

또한, 다양한 오픈 소스 기반의 DBMS는 각자 자기만의 인터페이스를 가지고 있다. 따라서 만약에 기존에 이미 다른 DBMS를 사용한 업체에서 오픈 소스 기반의 DBMS를 적용하고자 한다면 기존에 적용되어 있던 인터페이스를 모두 제거하고 다시 새로운 인터페이스를 적용해야 한다. 이러한 포팅 상의 문제점은 DBMS를 새로이 적용할 때 많은 장애가 된다. 이러한 문제점을 해결하기 위해서 다음과 같은 2가지 방법을 적용할 수 있다.

- ODBC 인터페이스의 제공
- 별도의 포팅 계층을 제공

전자의 경우에는 ODBC라는 표준화된 인터페이스에 맞추어서 오픈 소스 기반의 DBMS의 드라이버를 제공함으로서, 사용자는 손쉽게 DBMS를 사용할 수 있다. ODBC 드라이버가 중간 포팅 계층의 역할을 담당하는 것이다. 이미 대부분의 오픈 소스 기반 DBMS는 이를 사용할 수 있도록 준비되어 있다.

후자의 경우에는 각 DBMS가 ODBC 드라이버를 사용할 때 다른 솔루션과 비교하여 성능상의 문제가 존재할 때 자신만의 포팅계층을 구축하는 것이다. 그리고, 그 포팅 계층에서는 다른 DBMS 인터페이스와의 부정합을 완화시켜주는 역할을 담당한다. 이때 성능의 최대 이슈가 될 수 있는 이 포팅 계층의 설계가 매우 중요하다.

오픈 소스기반의 DBMS 솔루션으로 여러가지가 존재하지만, 실제로 모바일 기기가 가지고 있는 특수한 홖경을 만족시킬 수 있는 솔루션은 많지 않다. 각 솔루션의 장단점을 파악하여, 사용하고자 하는 모바일 기기에 맞는 최적의 솔루션을 적용하도록 해야 할 것이다.

참고문헌
1. www.mysql.com
2. www.sqlite.org
3. http://www.postgresql.org/
4. www.oracle.com

출처: http://groups.google.com/group/android-developers/browse_thread/thread/f1763b9a0c63653e

I would very explicitly NOT develop a MySQL App on the Android.
안드로이드에서 MySQL 개발을 하지 마십시오.

While you could perhaps get the JDBC driver to run on Android, this is the wrong approach from a architectural standpoint.
Android에서 돌리기 위해 JDBC 드라이버를 얻어야 할텐데요, 설계적 관점에서 이는 잘못된 접근 방식입니다.

You won't get the performance, scalability, maintainability, reliability, nor security characteristics you'd like.
수행성, 가용성, 관리성, 신뢰성, 보안성.. 그 어느것 하나 제대로 되지 않을겁니다.

Instead, expose your client-side functionality in a web service.
대신, 웹 서비스를 통해 클라이언트 쪽 기능을 하게 할 수는 있습니다.

For most purposes, I'd suggest a RESTfull web service, but SOAP is also an option.
대부분은, RESTfull 방식의 웹 서비스를 추천하지만 SOAP 또한 방법 중 하나죠.

JSON is often a good alternative to XML -- especially if you will be interacting with this service via a browser.
JSON은 XML을 훌륭하게 대체해 줍니다. 특히 브라우저를 통해 서비스 통신을 하게 된다면 말이죠.

If you put SQL in your client, you are basically screwed.
SQL을 클라이언트에 넣었다면, 근본적으로 완전 망하는겁니다.

You will NEVER be able to alter your schema, or introduce some non-DB processing, or split the data between databases, or make any of a host of other changes, because some people may never upgrade their apps.
스키마 변환이라든가 non-DB prosessing, DB 간 데이터 분리, 어떤 변화를 가지는 host 생성, 등은 절대 불가능 하겠죠. 왜냐하면 일부 유저는 프로그램 업데이트를 하지 않으니까요.

Well, OK, you can say "screw them", and change it anyway, but they'll ding you in the marketplace ratings.
뭐, 망하면 망할테라지라고 해버리고 어떻게든 바꿔버린다면, 뭐 시장 결과는 뻔하겠죠.

Especially in a mobile app, you want a looser coupling.
특히 모바일 app에서는 느슨한 커플링이 필요합니다.

With a web service, you can simultaneously provide multiple versions of the same service (perhaps distinguished only by a revision indicator).
웹서비스를 통해서라면, 같은 서비스를 여러 버전으로 하여 지속적으로 제공해 줄 수 있습니다. (아마 revision indicator를 통해야만 하겠죠.)

You can do server-side caching to take a load off your database. You could even move to a different database entirely.
또 데이터베이스 서버측의 로드를 줄여줄 수도 있습니다. 데이터베이스 전체를 다 바꿔버릴수도 있구요.

Also, connection failures will be frequent. With MySQL, you'd have to pay considerable attention to recovering from connection failures.
또한, 연결 실패가 빈번하게 일어날텐데, MySQL을 쓰면 연결 실패를 복구하는것에 대해 아주 신중하게 고려해야만 하죠.

With a web service, a single call may fail, but because the communication itself is stateless (if designed well), you can just retry that one failing call.
웹서비스를 이용한다면, 단일 호출이 실패하더라도 설계가 잘 되있는한 통신 자체는 stateless(?)이기 때문에 그냥 실패한 호출을 재시도하기만 하면 되죠.

You do have to think carefully about transaction boundaries, and try to accomplish more with a single call, rather than beginning a transaction, doing a bunch of stuff, and the committing.
트랜젝션 바운더리에 대해서도 신중해야 할텐데 하나 이상의 호출을 수행해야 한다면, 그냥 트랜젝션의 시작부터 모든 일들을 한꺼번에 수행하고 마지막에 committing만 하면 되죠.

That's a good thing -- you'll get much better performance, because the round-trip time through the mobile network will be poor.
이건 매우 좋은겁니다 -- 수행성이 훨씬 나아지죠. 왜냐하면 모바일 네트워크를 통해 데이터가 왔다갔다 하는건 엄청난 시간이 걸리는 작업이니까요.

You'll also be rewarded with much superior reliability -- a single MAKE-ALL-THESE-CHANGES call happens in a shorter period of time, and is much less likely to fail due to the network than a series of BEGIN-EDIT-EDIT-EDIT-EDIT-COMMIT operations.
그리고 훨씬 나은 보안성을 얻을 수 있구요. 한번으로 여러 호출을 한꺼번에 수행하는것은 시간도 더 짧게 들고 네트워크를 통한 호출 실패를 확 줄여줍니다.

All in all, there's very good reason why nobody uses MySQL on Android, and it has nothing to do with limitations on Android.
이 모든것들이 아무도 Android 에서 MySQL 을 쓰지 않는 이유가 되겠죠. 안드로이드의 한계와는 아무 상관이 없습니다.

The same arguments actually apply to ANY client-side use of MySQL, it's just that they get even stronger on a mobile platform.
MySQL 을 사용하는 어떠한 클라이언트 라도 동일한 논쟁이 발생합니다. 단지 모바일 플랫폼 상에서는 더욱 강력하게 발생할 뿐이죠.

흠... 이건 정말이지.. 안드로이드 위에서의 MySQL 이야기가 아니라, 네트워킹을 통해 db access 를 하는 모든 클라이언트-서버 시스템의 문제가 아닐까 하는데 -_-;;;; 결국 걍 RESTfull 방식으로 데이터 전송 하라는 거잖아.;; 그거 몰라서 안하는게 아니고 걍 클라이언트 내부적으로 데이터 관리를 용이하기 위해 쓰는 DB 라면 이야기가 달라지는거 아닌가... 내가 잘못 이해하고 있는건가....
어짜피 내부적으로만 쓰는거면 (당연히 차후 데이터 스키마를 바꾸게 된다거나 할일이 없어야겠지!) MySQL 에서 서버측 라이브러리를 제공하니 이를 링크해서 쓰게 되는건데..... 쩝. -_-

아, 물론.;; 안드로이드에서 제공하는 SQLite 를 쓰는게 베스트이지만 지금 제가 이 작업을 하는 이유가 안드로이드와 임베디드 리눅스, 윈도우 CE 모두에서 돌아가는 DB 조사를 하고 있는 중이기 때문에.;;;; 수행성과는 상관없이 말입니다.

*추신-막번역입니다 오역부분 댓글주시면 수정하겠습니다. 감사.

--- GestureRecognizer.cs 2009-08-26 11:53:24.000000000 -0000
+++ GestureRecognizer.cs 2010-02-26 09:46:33.000000000 -0000
@@ -30,12 +30,13 @@
private static readonly object EndEvent = new object();
private static readonly object SelectEvent = new object();
private static readonly object DoubleSelectEvent = new object();
private static readonly object HoldEvent = new object();
private static readonly object PanEvent = new object();
private static readonly object ScrollEvent = new object();
+ private WndProcHook wndProcHook = null;

private Control targetControl;

///

@@ -36,27 +37,31 @@

private Control targetControl;

///

{
if (value != this.targetControl)
{
if (this.targetControl != null)
{
// remove the WndProc hook for the previous targetControl
- Hook.RemoveHook(this.targetControl, WndProc);
+ if (wndProcHook != null)
+ {
+ Hook.RemoveHook(this.targetControl, wndProcHook);
+ }
this.targetControl = null;
}

if (value != null)
{
// add the WndProc hook for the current targetControl
this.targetControl = value;
- Hook.AddHook(this.targetControl, WndProc);
+ wndProcHook = new WndProcHook(WndProc);
+ Hook.AddHook(this.targetControl, wndProcHook);
}
}
}