Ich baue eine umfassende Webanwendung. Natürlich können Sie im Offline-Modus im lokalen Datenspeicher speichern. Ich möchte in der Lage sein, über verschiedene Geräte hinweg zu synchronisieren, so dass die Leute auf einem Rechner arbeiten, speichern, sich dann auf einen anderen Rechner begeben und ihre Daten laden können.
Die Fragen sind:
1) Ist es eine schlechte Idee, json auf dem Server zu speichern? Warum sollte der JSON auf dem Server in Modellobjekte zerlegt werden, wenn er nur als JSON an den (anderen) Client (s) zurückgegeben wird?
2) Ich bin mir nicht sicher, ob ich dafür eine NoSql-Technologie ausprobieren möchte. Ich zerbreche den Json nicht, denn die einzigen Beziehungen in der Datenbank würden jetzt von einem Benutzerkonto zu ihren Einträgen führen. Anders als die Benutzerdaten wäre das Domänenmodell ein String, der json ist. Beratung willkommen.
Theoretisch könnte ich in Zukunft etwas auf dem Server bearbeiten oder kompliziertere Beziehungen aufbauen. Mit anderen Worten, im Moment würde ich nur den JSON retten, aber in Zukunft möchte ich vielleicht ein traditionelleres Beziehungssystem. Würde NoSQL-Ansatz dem im Weg stehen?
3) Gibt es Sicherheitsbedenken? JS Injektion zum Beispiel? Theoretisch kann der Benutzer für diesen Anwendungsfall zumindest jetzt nichts eingeben.
Vielen Dank im Voraus.
EDIT - Danke für die Antworten. Ich habe die Antwort gewählt, die ich gemacht habe, weil sie sich ausführlich mit den Vor- und Nachteilen von NoSql befasst hat.
JSON auf dem SERVER
Es ist überhaupt keine schlechte Idee, JSON auf dem Server zu speichern, besonders wenn Sie mit einer NoSQL-Lösung wie MongoDB oder CouchDB arbeiten. Beide verwenden JSON als ihr natives Format (MongoDB verwendet tatsächlich BSON, aber es ist ziemlich ähnlich).
noSQL-Ansatz: Annahme von CouchDB als Speichermodul
Sicherheit
Stellen Sie sicher, dass Sie die JSON-Dokumente mit dem Browser JSON.parse oder einer JavaScript-Bibliothek, die sicher ist (json2.js), analysieren.
Fazit
Ich denke, der Grund, warum ich vorschlagen würde, mit noSQL hier zu gehen, vor allem CouchDB, ist, dass es all die harten Sachen für dich erledigen wird. Die Replikation wird für die Einrichtung ein Kinderspiel. Sie müssen sich keine Gedanken über Nebenläufigkeit machen, usw.
Das heißt, ich weiß nicht, welche Art von App Sie bauen. Ich weiß nicht, was deine Beziehung zu den Kunden sein wird und wie einfach es ist, dass sie CouchDB auf ihre Maschinen bringen.
Links
Nachdem ich mir die App angeschaut habe, glaube ich nicht, dass CouchDB eine gute clientseitige Option sein wird, da Sie nicht verlangen, dass Leute eine Datenbank-Engine installieren, um soduku zu spielen. Das heißt, ich denke immer noch, es wäre eine großartige serverseitige Option. Wenn Sie die Server-CouchDb-Instanz mit dem Client synchronisieren möchten, könnten Sie etwas wie BrowserCouch verwenden, was eine JavaScript-Implementierung von CouchDB für lokale ist. Speicher.
Wenn die meiste Verarbeitung auf der Client-Seite mit JavaScript erfolgt, sehe ich kein Problem darin, JSON direkt auf dem Server zu speichern.
Wenn Sie nur mit neuen Technologien herumspielen möchten, können Sie gerne etwas anderes ausprobieren, aber für die meisten Anwendungen gibt es keinen wirklichen Grund, von traditionellen Datenbanken abzuweichen, und SQL macht das Leben einfacher .
Solange Sie die Standardfunktion JSON.parse zum Analysieren von JSON-Zeichenfolgen verwenden, können Sie sicher sein. Einige Browser (z. B. Firefox 3.5 und höher) verfügen bereits über eine native Version, während Crockfords json2.js kann diese Funktionalität in anderen replizieren.
Lesen Sie einfach Ihren Post und ich muss sagen, dass ich Ihre Herangehensweise sehr mag. Sie kündigt die Art und Weise an, wie viele Webanwendungen in der Zukunft funktionieren werden, sowohl mit einem Element des lokalen Speichers (für den getrennten Zustand) als auch dem Online-Speicher (der Master) Datenbank - um alle Kundendatensätze an einem Ort zu speichern und mit anderen Clientgeräten zu synchronisieren.
Hier sind meine Antworten:
1) Speichern von JSON auf dem Server: Ich bin mir nicht sicher, ob ich die Objekte als JSON speichern würde. Dies ist möglich, wenn Ihre Anwendung ziemlich einfach ist Daten (Ausführen von Berichten und Senden von E-Mails an einen Stapeljob zum Beispiel). Ich würde lieber JSON für die Übertragung der Informationen selbst und eine SQL-Datenbank für die Speicherung verwenden.
2) NoSQL-Ansatz: Ich denke, Sie haben dort Ihre eigene Frage beantwortet. Mein bevorzugter Ansatz wäre, jetzt eine SQL-Datenbank zu erstellen (wenn die zusätzliche Ressource kein Problem ist), auf diese Weise ersparen Sie sich ein wenig Arbeit beim Einrichten der Datenzugriffsebene für NoSQL, da Sie sie wahrscheinlich entfernen müssen in der Zukunft. SQLite ist eine gute Wahl, wenn Sie kein voll funktionsfähiges RDBMS wünschen.
Wenn das Schreiben eines Schemas zu mühsam ist und Sie dennoch JSON auf dem Server speichern möchten, können Sie ein JSON-Objektverwaltungssystem mit einer einzelnen Tabelle und einigen Analysen auf der Serverseite zusammenführen, um relevante Datensätze zurückzugeben. Dies ist einfacher und erfordert weniger Berechtigungen als das Speichern / Löschen von Dateien.
3) Sicherheit: Sie haben erwähnt, dass momentan keine Benutzereingaben vorgenommen werden:
"für diesen Anwendungsfall nicht der Benutzer gib etwas ein "
Aber am Anfang der Frage haben Sie auch erwähnt, dass der Benutzer
kann"Arbeiten auf einer Maschine, speichern, dann holen auf einer anderen Maschine und laden Sie ihre Sachen "
Wenn dies der Fall ist, wird Ihre Anwendung Benutzerdaten speichern, es spielt keine Rolle, dass Sie nicht eine nette GUI dafür zur Verfügung gestellt haben, Sie müssen sich um Sicherheit von mehr als einem Standpunkt und% co_de sorgen % oder ähnliche Tools lösen nur die Hälfte des Problems (clientseitig).
Grundsätzlich müssen Sie auch den Inhalt Ihrer POST-Anfrage auf dem Server überprüfen, um festzustellen, ob die gesendeten Daten gültig und realistisch sind. Die Integrität des JSON-Objekts (oder aller Daten, die Sie speichern möchten) muss auf dem Server überprüft werden (mit PHP oder einer anderen ähnlichen Sprache) BEVOR Sie in Ihrem Datenspeicher speichern, da jemand Ihre Javascript-Ebene leicht umgehen kann "Sicherheit" und manipulieren Sie die POST-Anfrage, auch wenn Sie dies nicht beabsichtigt haben und dann sendet Ihre Anwendung die bösartige Eingabe aus dem Client sowieso.
Wenn Sie die Server-Seite der Dinge aufgeräumt haben, dann wird JSON.parse ein bisschen obsolet im Hinblick auf die Verhinderung von JS-Injektion. Dennoch ist es nicht schlecht, die Extra-Ebene zu haben, besonders wenn Sie auf Remote-Website-APIs angewiesen sind, um einige Ihrer Daten zu erhalten.
Ich hoffe, dir ist das nützlich.
Tags und Links sql html5 json nosql rich-internet-application