JDBC vs 안드로이드용 웹 서비스

JDBC vs 안드로이드용 웹 서비스

안드로이드 장치를 내 SQL 또는 Postgresql에 연결할 때 어떤 방법을 사용해야 하는지 누가 내 딜레마에 대해 대답해 줄 수 있습니까?

저는 오류와 문제없이 두가지 방법으로 할 수 있고, 눈에 띄는 차이는 없지만 모두가 jdbc 드라이버와 직접 연결을 사용하는 대신 웹 서비스를 추천합니다.

누가 몇 가지 사실을 가지고 그 이유를 설명해 줄 수 있습니까?

편집: jdbc보다 더 간단하고 더 적은 시간이 필요하다고 언급하지 않았습니다.그렇다면, 왜 웹 서비스를 이용하는 것일까요, 아니면 왜 안 되는 걸까요?

전화기와 휴대용 장치의 실제 운영 환경을 고려하지 않기 때문에 JDBC를 사용하는 것이 더 간단하고 빠르다고 생각하는 것입니다.이들은 종종 버그가 많은 트래픽 다시 쓰기 프록시와 미친 방화벽을 통해 연결이 잘 되지 않습니다.일반적으로 패킷 손실률이 높고 변동이 심한 네트워크 전송 계층을 사용하고 있으며 짧은 시간 내에 수 많은 규모로 변화합니다.TCP는 이 환경에서는 그다지 좋지 않으며 특히 오래 지속되는 연결에 어려움을 겪고 있습니다.

웹 서비스의 주요 이점은 다음과 같습니다.

• 최소한의 상태로 짧은 수명의 연결을 가지고 있어 기기가 WiFi 네트워크를 셀룰러로 전환하거나 또는 셀룰러에서 잠시 연결이 끊길 때 원래 위치로 쉽게 돌아갈 수 있습니다.

• 가장 끔찍하고 엄격한 웹 프록시를 제외한 모든 것을 통과할 수 있습니다.

JDBC 직접 연결에 문제가 발생하는 경우가 종종 발생합니다.한 가지 과제는 서버가 클라이언트가 동시에 비활성 상태라고 결정하지 않을 수도 있기 때문에 비활성 연결 시간을 안정적으로 조정하고 세션을 재설정하고 이전 세션이 보유한 잠금을 해제하는 것입니다.다른 하나는 패킷 손실로 인해 작업 속도가 매우 느리고 데이터베이스 트랜잭션이 오래 지속되며 잠금 기간 및 트랜잭션 정리 작업과 관련된 문제가 발생합니다.또한 태양 아래에서 정신 나간 고장 난 프록시와 방화벽을 모두 만나보실 수 있습니다. 이를 지원하는 프록시들 말입니다.CONNECT않은 경우,가 있는 저장 기능이 할 수 모든 지연 HTTP우,이로 전환되는 버그가 있는 상태 저장 연결 추적 기능이 있는 방화벽, 상상할 수 있는 모든 NAT 문제, 지연 시간을 줄이기 위해 TCP ACK 를 생성하는 캐리어, 패킷 및 조정,는 신경 .패킷 손실 검색 및 윈도우 크기 조정, 엉뚱한 포트 차단 등과 관련된 문제는 신경 쓰지 마십시오.

모든 사람이 HTTP를 사용하기 때문에 적어도 다른 어떤 것보다 훨씬 더 자주 HTTP가 작동할 것으로 예상할 수 있습니다.일반적인 웹사이트들이 모바일 웹 앱에서도 REST+JSON 커뮤니케이션 스타일을 사용하는 지금은 특히 그렇습니다.

고유한 요청 토큰을 사용하여 웹 서비스 호출을 idempotent로 쓸 수도 있습니다.이렇게 하면 앱이 데이터베이스에 대한 작업을 두 번 수행할 우려 없이 수정 요청을 다시 보낼 수 있습니다.idimpotent와 idimpotent를 정의합니다.

진지하게 말하자면, 모바일 기기에서 JDBC를 사용하는 것이 지금은 좋은 생각처럼 보일 수도 있지만, 제가 생각해 볼 수 있는 유일한 방법은 모바일 기기가 모두 제 직속의 신뢰성이 높은 단일 WiFi 네트워크에 있는 경우뿐입니다.가능하면 데이터베이스 성능 관리를 위해 이를 피하고자 합니다.PgBouncer와 같은 것을 사용하여 서버 측의 여러 장치 간의 연결을 풀링할 수 있으므로 연결 풀링은 큰 문제가 되지 않지만, 손실된 연결과 포기된 연결을 정리하는 것은 작업을 수행하는 데 필요한 tcp keepalive 트래픽과 포기된 연결에서 발생하는 장기간 정체된 트랜잭션과 마찬가지입니다.

몇 가지 이유를 생각할 수 있습니다.

1. 데이터베이스에 대한 JDBC Android 드라이버 지원.
2. 다양한 Android 장치에 걸친 연결 풀링은 이들을 모니터링하고 제한하는 것을 어렵게 합니다.
3. DB에서 안드로이드로 전송되는 결과 세트는 대역폭과 배터리 전력을 많이 소모하게 됩니다.
4. 프록시는 일반적으로 장치에 대한 HTTP 액세스를 허용합니다.
5. 데이터베이스를 클라이언트에 직접 노출하는 것은 보안에 영향을 미칩니다.

웹 서비스는 인증/서비스 품질/승인/조건부 GET 요청/오류 처리 등 JDBC 연결 위에 추가 기능을 제공할 수 있습니다.JDBC는 이 중 어떤 것도 할 수 없습니다.

크레이그 링거가 한 말 외에도 JDBC는 또 다른 문제가 있습니다. 그것은 당신의 데이터베이스를 세상에 노출시키도록 강요할 것입니다.Android 장치에서 액세스하려면 앱에 데이터베이스 자격 증명을 제공해야 하며 데이터베이스에는 공용 액세스 권한이 있어야 합니다.

웹 서비스 또는 RESTful API를 사용하는 것은 애플리케이션을 안전하게 만드는 방법입니다.

또 다른 옵션은 SymmetricDS와 같은 데이터베이스 동기화 도구를 사용하는 것입니다.

이렇게 하면 서버에는 Postgres 데이터베이스가, 태블릿에는 SQLite 데이터베이스가 표시됩니다.

SymmetricDS는 연결이 가능한 경우 HTTP를 통해 데이터베이스를 동기화합니다.물론 DB 전체를 동기화할 필요는 없고, 관련된 부분만 동기화할 필요가 있습니다.

(SymmetricDS에 가입되어 있지 않습니다)

TL;DR: 상황에 따라 다릅니다!

플레이스토어 같은 것을 위한 퍼블릭 도메인/일반 앱을 만들 때, 저는 주로 동료 응답자들과 함께 합니다.DB를 "모든 사람"에게 개방하는 것은 일반적으로 좋은 생각이 아닙니다(특히 권한이 잘못 설정되었거나 전혀 구성되지 않은 경우).

그러나(!) 물류, 인벤토리 등을 위한 Android 핸드헬드 장치와 같이 회사의 네트워크 경계 내에서 내부적으로 사용할 수 있는 무언가를 만들 때는 이야기가 완전히 달라질 수 있습니다.이 경우 대부분의 경우 JDBC나 그와 비슷한 직접 연결을 사용하는 것을 확실히 권장합니다.다음과 같은 이유:

• 고장 지점이 하나 줄어듭니다.
• 데이터 구조를 유지하고 최신 상태로 유지하기 위한 한 가지 이점
• CI/CD, 테스트 등을 지속적으로 수행할 수 있는 것이 하나 더 있습니다.

이것은 - 나의 겸손한 의견이지만 - 연결 풀링, 재정립 등의 (한 번 시행) 노력보다 더 나쁠 수 있습니다. (만약 정말 필요하다면 - 거기서 조기 최적화를 조심하세요.)

하지만 공공 프로젝트의 경우... 읽기 액세스만 필요한 경우라면 저도 상상해 볼 수 있습니다. 추가는 허용하고 삭제나 수정은 허용하지 않는 특정 테이블만 있다면 말이죠.보안을 유지하기 위해 적용할 수 있는 몇 가지 트릭(특정 테이블의 경우 ID 비밀로 읽기는 허용하지만 다른 테이블의 경우 일반 읽기는 허용하지 않음)이 있지만 이에 대해 생각할 것이 많고 놓쳐야 할 것이 많습니다.따라서 일반적으로 퍼블릭 도메인 클라이언트에서 SQL 연결을 허용하는 것은 나쁜 관행이라고 생각합니다.하지만 그렇다고 해서 스스로에게 "왜"라고 묻고 특정한 상황을 보는 것을 방해하지는 마세요.그럴만한 이유가 있을 수도 있습니다.특히 "덜"하기 때문에 더 나은 경우가 많습니다.확실히 다릅니다.

사용 권한이 올바르게 설정되어 있더라도 많은 것이 잘못 사용될 수 있으며(그리고 거의 방해받지 않을 수 있음), 고객에게 직접 연결될 수 있음을 유의하십시오(게다가 연결 문제도 처리해야 함).

참고 사항:이러한 고려 사항 중 많은 부분이 GraphQL과 같은 기술을 사용하는 것과 관련이 있습니다. GraphQL은 몇 가지 유사성을 공유합니다(그러나 연결 문제는 없고 약간 더 안전한 제어).

또한 RLS(Row Level Security)와 같은 기능은 보안(데이터베이스 또는 테이블 레벨)을 데이터베이스의 행에 대한 개별 규칙으로 이동하여 이 경로(예: 서버리스 앱)로 이동합니다.일반적으로 "익명의" 사용자/접속자가 일반 게시물에 로그인하거나 읽을 수 있는 특정 권한을 허용하는 어느 정도 수준의 인증을 구현해야 합니다.예를 들어, 사용자가 해당 게시물/엔트리의 작성자인 경우 행에 대한 편집만 허용하는 규칙이 될 수 있습니다."tablename.authorId = @CURRENT_USER").

언급URL : https://stackoverflow.com/questions/15853367/jdbc-vs-web-service-for-android