2010-12-29 4 views
6

Android 클래스 SQLiteOpenHelper에는 읽을 수있는 데이터베이스와 읽고 쓸 수있는 데이터베이스를 반환하는 메서드가 있습니다. 현재 필자는 쓰기 가능한 데이터베이스 만 사용하고 문제는 없지만 비동기 작업 (또는 작업) 만 읽는 경우에만 읽기 전용으로 변경하면 어떤 이점이 있는지 궁금합니다.읽을 수있는 SQLite 데이터베이스를 사용하는 이유

성능상의 이점이있을 수 있지만 실제 수치는 언급하지 않았습니다. 또한 읽기 가능 및 쓰기 가능간에 전환을 유지하면 변경으로 인해 모든 성능 이점을 제거 할 수있는 오버 헤드가 발생합니다.

아무에게도 실제 숫자 또는 경험이 있습니까? 별도의 액세스를 구현할 가치가 있습니까?

+1

나는 일반적으로이를 성능보다는 보호 수단으로 해석했습니다. 모든 Java 클래스/메소드/데이터 멤버를 public으로 선언 할 수 있지만, 우리는'protected','private' 및 package-'protected'를 사용하여 스스로를 망치지 않도록합니다. 마찬가지로 읽을 수있는 데이터베이스는 코딩 오류를 잡는 데 도움이 될 수 있습니다. 즉,'SQLiteOpenHelper'는 미래의 getWritableDatabase() 호출에서 데이터베이스를 투명하게 "업그레이드"하기 때문에이 값은 다소 제한적일 수 있습니다. – CommonsWare

+0

그 힌트를 가져 주셔서 감사합니다. 나는 아래에 언급 된대로이 단계에서 귀찮게하지 않을 것이라고 생각한다. –

답변

5

성능상의 이점에 대해서는 언급 할 수 없지만 모든 '데이터'액세스에 대해서는 항상 '우수 사례'(또는 '우수 사례')의 원칙에 따라 노력합니다. 소스 (텍스트 파일, DB 또는 무엇이든).

액세스 수준을 결정할 때 결정할 사항 (일반적으로 Android 만 해당)을 확인하고 수행 할 작업뿐만 아니라 외부 영향도 내려야합니다. 이 같은 방법으로 데이터 소스 '열'하셨을 수도 있습니다 경우 - 내가 생각할 수있는

두 가지 예 ...

  1. 외부 프로세스는 데이터를 유지하는 책임이있을 수있는 경우 그 유지 보수 단계 동안 다른 프로세스가 '읽기'액세스를 제외한 모든 것을 차단합니다. 이 경우 이 필요하지 않으면 읽기/쓰기 액세스를 요청하면 코드가 액세스가 거부됩니다.
  2. 데이터 무결성을 손상시킬 수있는 위험 - 외부 세계의 시스템에 해킹하는 것은 내부 코드를 사용하여 보안 구멍을 통해 수행 할 수 있습니다. 내부 코드는 실제로 '읽기'권한 만 있으면 데이터에 대한 읽기/쓰기 권한이 있습니다.

좋아, 요점은 안드로이드와 관련이있을 수도 있고 그렇지 않을 수도 있습니다 (특히 데이터 소스가 앱에만 해당되는 경우). 그러나 말했듯이 나는 일반적인 것들을보고 " 접근. '쓰기'권한이 필요하지 않으면 요청하지 않습니다.

+0

나는 귀하의 의견에 동의하지만이 경우에는 Android에 적용되지 않습니다. db 서버는 없지만이 애플리케이션에 고유 한 고유 한 db 파일 및 액세스 코드 (naitve 및 via dalvik VM)가 있습니다. 각 응용 프로그램 내에서 db 액세스는 독점 (적용)되고 순차적입니다. 다른 응용 프로그램에 db가있는 경우 별도의 db 파일이며 액세스 용 및 모든 항목 (각 응용 프로그램마다 고유 한 VM이 있음)이 있습니다. 또한 위에서 언급 한 javadoc은 동일한 객체가 반환되어 모든 것이 더 의미가 없으므로 심지어 javadoc에서도 반환된다는 것을 알 수 있습니다. –

+0

@Manfred Moser : 예, 자신의 VM 내 앱이 존재한다는 것을 알고 있습니다. SQLite에 익숙하지 않은 서버 (여러 플랫폼에서 잠시 동안 SQLite를 사용해 왔습니다). 그러나 모든 SQLite DB는 'in-process'에 존재합니까? 예를 들어 SD 카드에서 생성 될 수있는 것은 무엇입니까? 또한, 같은 응용 프로그램 내에서 다른 스레드로부터의 액세스는 어떻습니까? CommonsWare의 의견은 모든 것을 '공개'로 만들지 않았 음을 의미합니다. 기본적으로 '모범 사례'와 그 모든 것입니다. 결코 당신의 '경기장'이 변하지 않을 것이라고 가정하지 마십시오. – Squonk

+0

나는이 단계에서 당신의 대답을 수락 할 것입니다. 이 단계에서 저는 리팩토링에 대한 노력을하지 않을 것이라고 생각합니다. 제 경우에는 끊임없이 닫고 열면 성능이 저하 될 것이기 때문입니다. 보호 측면에서 데이터가 중요하지 않기 때문에 가치가 없습니다. –

6

좋은 질문입니다. 나 한테서 번호가 없어.

"이 (getReadableDatabase) (SQLLiteOpenHandler javadoc의에서) 가장 가까운 설명은 몇 가지 문제가 된 경우가 아니면, 전체 디스크로, 읽기 전용으로 열 수있는 데이터베이스가 필요합니다 getWritableDatabase()에 의해 반환 된 같은 객체 일 것이다.에 이 경우 문제가 해결되면 getWritableDatabase()에 대한 향후 호출이 성공할 수 있습니다.이 경우 읽기 전용 데이터베이스 객체가 닫히고 읽기/쓰기 객체가 반환됩니다.

+0

니스 찾기 및 내 대답에서 언급 한 첫 번째 지점에서 실패 방지하기 위해 어떤 식 으로든 갈 것입니다. – Squonk

+0

@Manfred Moser 내 답변에서 말한 것처럼 .... 우리가이 한 가지 방법 또는 다른 방법을 증명할 수 있는지 확실하지 않은 경우 (즉, 유익한 이점이있는 경우). 여기에 하나의 (확인되지 ​​않은) 이유가 있습니다. 이것이 퍼펙트 영향을 줄 수 있다고 생각합니다. getWritableDatabase()를 사용하는 경우 close() 메소드를 호출해야합니다. 그렇지 않으면 LogCat에서 많은 빨간색이 나타납니다. 여기서 (이 부분은 확인되지 않음) getReadableDatabase()는 close() 메소드에 대한 호출을 요구하지 않습니다. 응용 프로그램이 데이터베이스를 자주 닫는 경우 성능에 영향을 줄 수 있습니다 (!). – GSree

관련 문제