8

フル機能のWebアプリケーションを構築しています。当然、「オフライン」モードのときにローカルデータストアに保存できます。デバイス間で同期できるようにしたいので、人々は1つのマシンで作業し、保存してから、別のマシンに乗って自分のものをロードできます。

質問は次のとおりです。

1）サーバーにjsonを保存するのは悪い考えですか？サーバー上のjsonを（他の）クライアントにjsonとして返すだけの場合、なぜモデルオブジェクトに解析するのですか？

2）このためにNoSqlテクノロジーを試してみたいかどうかわかりません。私はjsonを分解していません。今のところ、db内の唯一の関係は、ユーザーアカウントからそれらのエントリへの関係です。ユーザーデータ以外のドメインモデルは、jsonである文字列になります。アドバイスを歓迎します。

理論的には、将来的にはサーバー上で処理を実行したり、より複雑な関係を設定したりする可能性があります。つまり、今はjsonを保存するだけですが、将来的には、より従来型のリレーショナルシステムが必要になる可能性があります。NoSQLアプローチはこれを邪魔しますか？

3）これにセキュリティ上の懸念はありますか？たとえばJSインジェクション？理論的には、このユースケースでは、少なくとも現時点では、ユーザーは何も入力できません。

前もって感謝します。

編集-答えてくれてありがとう。NoSqlの長所と短所について詳しく説明したので、私が行った答えを選びました。

4

3 に答える 3

3

  1. ほとんどの処理がJavaScriptを使用してクライアント側で行われる場合、JSONをサーバーに直接保存しても問題はありません。

  2. 新しいテクノロジーを試してみたい場合は、別のことを試してみることを歓迎しますが、ほとんどのアプリケーションでは、従来のデータベースから離れる本当の理由はなく、SQLによって作業が簡単になります。

  3. JSON.parse標準関数を使用してJSON文字列を解析する限り安全です。一部のブラウザ（Firefox 3.5以降など）にはすでにネイティブバージョンがありますが、Crockfordのjson2.jsは他のブラウザでこの機能を複製できます。

于 2010-11-08T00:47:35.437 に答える
3

サーバー上のJSON

特にMongoDBやCouchDBなどのnoSQLソリューションを使用する場合は、JSONをサーバーに保存することはまったく悪い考えではありません。どちらもネイティブ形式としてJSONを使用します（MongoDBは実際にはBSONを使用しますが、非常によく似ています）。

noSQLアプローチ：ストレージエンジンとしてCouchDBを想定

  • レプリケーションと同時実行処理に組み込まれています
  • 非常にシンプルなRestAPIで、HTTPを使用してデータベースと通信します。
  • データをJSONとしてネイティブに保存し、blobやテキストフィールドには保存しない
  • ドキュメントの複雑さを増し続けることを可能にする強力なビュー/クエリエンジン
  • オフラインモード。javascriptを使用してCouchDbと直接通信し、インターネットが利用できない場合でもアプリ全体をクライアントで実行し続けることができます。

安全

JSONドキュメントをブラウザのJSON.parseまたは安全なJavascriptライブラリ（json2.js）で解析していることを確認してください。

結論

ここでnoSQL、特にCouchDBを使用することをお勧めする理由は、すべての難しい作業を処理できるからだと思います。レプリケーションはセットアップが簡単になります。並行性などを心配する必要はありません。

とはいえ、どのようなアプリを作成しているのかわかりません。クライアントとの関係がどうなるのか、CouchDBをマシンに配置するのがどれほど簡単になるのかわかりません。

リンク

  1. CouchDB @ Apache
  2. CouchOne
  3. CouchDBの決定的なガイド
  4. MongoDB

アップデート：

アプリを見た後、数独をプレイするためにデータベースエンジンをインストールする必要がないため、CouchDBがクライアント側の良いオプションになるとは思いません。そうは言っても、それでもサーバー側の優れたオプションになると思います。サーバーのCouchDbインスタンスをクライアントと同期したい場合は、ローカルストレージ用のCouchDBのJavaScript実装であるBrowserCouchのようなものを使用できます。

于 2010-11-14T01:41:56.733 に答える
2

あなたの投稿を読んでください。私はあなたのアプローチがとても好きだと言わなければなりません。それは、ローカルストレージ（切断状態の場合）とオンラインストレージ（マスターデータベース-すべての顧客レコードを1つの場所に保存し、他のクライアントデバイスと同期します）。

これが私の答えです：

1）サーバーへのJSONの保存：オブジェクトをJSONとして保存するかどうかはわかりません。アプリケーションが非常に単純な場合は保存できますが、データの使用（レポートの実行とバッチでのメール送信）の作業が妨げられます。たとえば、仕事）。自分で情報を転送するためにJSONを使用し、それを格納するためにSQLデータベースを使用したいと思います。

2）NoSQLアプローチ：あなたはそこであなた自身の質問に答えたと思います。私が好むアプローチは、SQLデータベースを今すぐセットアップすることです（必要な追加のリソースが問題にならない場合）。そうすれば、NoSQLのデータアクセス層をセットアップする手間を少し節約できます。おそらく、データベースを削除する必要があるからです。将来。フル機能のRDBMSが必要ない場合は、SQLiteが適しています。

スキーマの作成が面倒で、サーバーにJSONを保存したい場合は、単一のテーブルとサーバー側での解析を使用してJSONオブジェクト管理システムをハッシュし、関連するレコードを返すことができます。これを行うことは、ファイルの保存/削除よりも簡単で、必要な権限も少なくなります。

3）セキュリティ：現時点ではユーザー入力がないとおっしゃいました：

「このユースケースでは、ユーザーは何も入力できません」

ただし、質問の冒頭で、ユーザーは次のことができると述べました。

「あるマシンで作業し、保存してから、別のマシンに乗って、それらのものをロードします」

この場合、アプリケーションはユーザーデータを保存します。ユーザーが保存するための優れたGUIを提供していなくてもかまいません。複数の観点からセキュリティについて心配する必要があります。またJSON.parse、同様のツールで解決するだけです。問題の半分（クライアント側）。

基本的に、サーバー上のPOSTリクエストの内容をチェックして、送信されるデータが有効で現実的であるかどうかを判断する必要もあります。データストアに保存する前に、JSONオブジェクト（または保存しようとしているデータ）の整合性をサーバーで検証する必要があります（phpまたは他の同様の言語を使用）。これは、誰かがjavascriptレイヤーを簡単にバイパスできるためです。 「セキュリティ」を設定し、POSTリクエストを改ざんすることを意図していなくても、アプリケーションはとにかく悪意のある入力をクライアントに送信します。

サーバー側を整理している場合は、JSON.parseJSインジェクションを防ぐという点で少し時代遅れになります。それでも、データの一部を取得するためにリモートWebサイトAPIに依存している場合は特に、追加のレイヤーがあることは悪くありません。

これがお役に立てば幸いです。

于 2010-11-08T20:06:44.673 に答える