2013-04-06 11 views
19

デバイスをmySQLまたはPostgreSQLに接続するために使用する方法を、自分のジレンマにどのような方法で回答できますか?Android用のJDBCとWebサービス

ノー顕著な違いで、すべてのエラーと問題なく両方の方法でそれを行うことができますが、誰も代わりに、JDBCドライバとの直接接続を使用してのWebサービスをお勧めします、

誰かがいくつかの事実と理由を説明できますか?

EDIT:私はそれがより簡単であり、jdbcでそれを行うのに必要な時間がより短いことを言いました。だから、なぜWebサービス、またはなぜですか?

+3

1. Webサービスを使用している場合は、他のクライアント(ipadなど)でも動作します。 2. Spring Data Restを見てください。これは、すばやく快適なWeb​​サービスを作成するのに役立ちます。 –

答えて

25

You 携帯電話やポータブルデバイスの実際の動作環境を考慮していないため、JDBCを使用する方が簡単で高速です。彼らはしばしばバグのあるトラフィック書き換えプロキシと非常識なファイアウォールを介してフレーク接続をします。彼らは、典型的には、短期間で多くの桁数で変化する、高いおよび可変のパケット損失率および待ち時間を有するネットワークトランスポート層を使用している。 TCPはこの環境では本当に素晴らしいものではなく、特に長時間の接続で苦労しています。 /それはデバイスがに、WiFiネットワークを切り替えたときにあなたがいた場所に戻って取得するのは簡単ですので

  • 、最小限の状態で短命な接続を持っている:

    ウェブサービスの主な利点は、それがあることです携帯電話から、簡単に接続を失うなど。そして

  • は、直接JDBCコネクションを持つすべてのほとんどのひどいと厳格なWebプロキシ

あなたは意志日常出会いの問題を通過することができます。 1つの課題は、デッド接続を確実にタイムアウトさせ、セッションを再確立し、古いセッションで保持されているロックを解除することです(サーバーは、クライアントが同時に停止したと判断しない可能性があります)。もう1つは、非常に遅い操作、長時間実行するデータベーストランザクション、および結果としてロックの持続時間とトランザクションクリーンアップタスクの問題を引き起こすパケット損失です。 CONNECTをサポートする太陽プロキシの下で、あらゆる種類の狂気と壊れたプロキシとファイアウォールも満たしますが、すべてのトラフィックがHTTPsであると仮定し、接続が失敗したり、半開きのゾンビ状態になったりするバグのあるステートフルな接続追跡機能を備えたファイアウォール。想像できるすべてのNAT問題。通信事業者は待ち時間を短縮するためにTCP ACKを生成し、パケットロスの検出とウィンドウサイジングで発生する問題には気を付けません。ワッキーなポートブロッキング。

誰もがにHTTPを使用しているため、動作することが期待できます。これは、一般的なWebサイトがモバイルWebアプリケーションでもREST + JSON通信スタイルを使用するようになった今、特に真実です。

また、ユニークな要求トークンを使用して、冪等番号にWebサービスコールを書き込むこともできます。これにより、データベースに対して2回のアクションを実行する恐れなく、変更要求を再送信することができます。 idempotenceおよびdefinining idempotenceを参照してください。

真剣に、モバイルデバイスからのJDBCは良いアイデアのように見えるかもしれませんが、モバイルデバイスがすべて私の直接的な管理下に高信頼性の単一のWiFiネットワーク上にあったと考えても唯一の方法です。それでも、可能であれば、データベースのパフォーマンス管理の理由からそれを避けるだろう。 PgBouncerのようなものを使用して、サーバ側の多くのデバイス間の接続をプールすることができます。接続プールは大きな問題ではありませんが、紛失して放棄された接続のクリーンアップは、放棄された接続からのトランザクション。

+0

ありがとうございます。サブクラス:なぜあなたはそれが直接のconnより遅いと思いますか?私はモバイルデバイス上のデータが必要なので、ボトルネックがそこにあります。直接接続を使用している場合、転送するデータが増えているとお考えですか? – fenix

+2

@StevanPopovあなたの問題は帯域幅ではなく、パケット損失やトランスポートが変更されたときのIPの切り替えに起因する長い接続ストールになります。ステートレスなWebサービスでは、完全なJDBC接続ではそれ以上の時間がかかり過ぎると、接続を断念して新たなリクエストを行うことができます。また、少ない往復で設定するのがはるかに迅速です。また、Webサービスで複数のクエリーの出力を収集したり、1つ目の結果に基づいて追加のクエリーを実行したりすることで、すべての結果を1つの結果としてレポートすることができます。 –

+0

ありがとうクレイグ、本当に私を確信してくれて、無料の知識に感謝します。橋を渡すこと(この場合はWS)は川を飛び越えるよりも簡単だと信じるのは難しいです。 複数の制限付きmySQLアカウントを使用しているため、トラフログファイルを監視できます。同じアカウントを使用してdbに接続すると、WSを介してどのように処理できますか? – fenix

4

私が完全に同意したCraig Ringer氏によると、JDBCには別の問題があります。データベースが世界に公開されることになります。アンドロイドデバイスでアクセスするには、アプリケーションにデータベースの認証情報を提供する必要があります。データベースには公開アクセス権が必要です。

WebServiceまたはRESTful APIを使用することは、アプリケーションを安全にするための方法です。

6

私はいくつかの理由、データベースの

  1. JDBCアンドロイドドライバのサポートと考えることができます。
  2. 接続さまざまなAndroid搭載端末でのプールは、それらを監視して制限することを困難にします。
  3. DBからアンドロイドに送信される結果セットは、の帯域幅バッテリーの多くを消費します。
  4. プロキシ usuallはデバイスへのHTTPアクセスを許可します。
  5. データベースを直接クライアントに公開すると、セキュリティの影響があります。

Webサービスは、/ 認証/品質サービスの/承認/条件付きGET要求などのJDBCコネクションの上に追加機能を提供することができますなどJDBCのいずれかを実行することはできませんエラー処理これら。

+0

私は前にセキュリティの議論をしましたが、今はそれほど確信していません。 DB内の適切に設計された権限モデルは、認証されたWebサービスを介したアクセスと同じくらい堅牢でなければなりません。確かに、あなたのDBには、PostgreSQL 9.2で修正された厄介なバグのような、リモートから悪用可能なバグがあるかもしれません...しかし、あなたのアプリケーションサーバは、現実のアプリケーションサーバの非常に複雑な可能性が非常に高いでしょう。 Webサービスを使用することは他の理由からも非常に良いアイデアですが、私はセキュリティの議論が水を保有しているとは思いません。本当に帯域幅+パワーもどちらもありません。 HTTP + JSONはうまくいきません。 –

+0

アプリサーバーの代わりに*直接DB接続*を使用している場合は、別のターゲットを取得することはできません。あなたが仲介appserver/webserverの背後にDBをロックすると、Webサービスを実行しているappserverを使用するIPを制限することも、プライベートネットワーク上に置くこともできません。 1つのターゲットを隠して別のターゲットを追加しました。私は、Webサービスは他のあらゆる種類の理由のためのより良いアイデアだと思うが、セキュリティはそうではない。 Webサービス層を通じた情報漏えいの制御を向上させることは、このアプローチのセキュリティの一種です。 –

+0

YのX _instead_を使用した場合、私のポイントのいくつかは適用されません。私は、アプリケーション層とDB層があるレベルで同等のセキュリティ問題を共有していることに同意します。 Postgresの悪用とWebサーバのハッシュ衝突の悪用が心に浮かび上がる。私は認証/認可と情報アクセスを提起しようとしていましたが、あなたが既にWSがそれらを確保するうえで良い仕事をしていることに同意していることがわかります。私たちは同じページにいます。 –

0

SymmetricDSのようなデータベース同期ツールを使用することもできます。

これは、サーバー上のPostgresデータベースと、タブレット上のSQLiteデータベースを言うことができます。

SymmetricDSは、接続が利用可能な場合にHTTP経由でデータベースを同期します。もちろん、関連する部分だけをデータベース全体と同期させる必要はありません。

(私はSymmetricDSと提携していません)

+1

このツールの簡単な例はありますか? AndroidのSQLiteの例 – fenix

関連する問題