# Frage zu JSON



## meisterfisch (24. Mai 2017)

Hallo,
ich hoffe ich bin der richtigen Abteilung. Es geht um Speicherung von Daten als JSON-Objekt.

Ich will eine eigene Filmdatenbank erstellen, da kommen so um die 10 000 Filme mit den entsprechnenden Daten zusammen. Ich habe ein paar Daten auch bereits eingelesen(nicht alle!) und alles funzt so weit (JSON parsen , daten darstellen...).

Das Jsonobjekt meiner filme sieht so aus


```
{"Filme":[{Film1},{Film2},....... ]
```


Wobei Film1,Film2.. wieder lange Jsonobjekte sind.

Jetzt meine Fragen.
Wenn ich das in eine txt abspeicher, dann wird nur eine Zeile in die txt Datei geschrieben.
Wie lang darf denn eine Zeile in einer txt sein? Ist dieses Vorgehen zum Speichern der Daten  sinnvoll?
Alternativ hatte ich gedacht, für jeden Film ein jsonobjekt in eine eigene txt datei zu speichern, nur dann bekomme ich sehr viele Textdateien in einem Ordner. Wie speichert man die Daten am besten ab?

Danke, ich hoffe das meine Frage nicht zu kompliziert und nachvollziehbar ist.

Schöne Grüße
meisterfisch


----------



## Dukel (24. Mai 2017)

10.000 Elemente? Wie wäre es mit einer Datenbank?


----------



## mrBrown (24. Mai 2017)

meisterfisch hat gesagt.:


> Wie lang darf denn eine Zeile in einer txt sein?


Das was dein OS als maximale Dateigröße her gibt 



meisterfisch hat gesagt.:


> Ist dieses Vorgehen zum Speichern der Daten sinnvoll?
> Alternativ hatte ich gedacht, für jeden Film ein jsonobjekt in eine eigene txt datei zu speichern, nur dann bekomme ich sehr viele Textdateien in einem Ordner. Wie speichert man die Daten am besten ab?


Kommt drauf an, was du damit machen willst. Eine Datei pro Dokument dürfte aber Unsinn sein...



Dukel hat gesagt.:


> 10.000 Elemente? Wie wäre es mit einer Datenbank?


Naja, das sind ja auch nur Dateien, die auf der Platte liegen


----------



## meisterfisch (24. Mai 2017)

@mrBrown Danke für die schnelle Antwort...

Datenbank(SQL) wäre wohl sinnvoll, habe ich auch schon mit rumprobiert aber, dort bin ich auf Probleme gestossen,die bei Json nicht auftreten.
Beispielsweise wenn eine Beschreibung Anführungsstriche(")hatte, bekam ich im Javaprogram eine Fehlermeldung, weil bei insert selbst Anführungsstriche als Trennzeichen genutzt werden.


----------



## thecain (24. Mai 2017)

Das liegt aber nicht an SQL sondern an deinem Code...


----------



## Thallius (24. Mai 2017)

Prepared statements lösen dieses Problem sehr elegant...


----------



## meisterfisch (24. Mai 2017)

Hallo,
@thecain  ja das richtig, ich konnte das Problem bloß nicht beheben

@Thallius   da muss ich mich erst einlesen,...mir scheint es auch besser zu sein, eine Datenbank zu benutzen, aber ich kenne mich auch noch nicht so gut aus mit SQL.


----------



## Tobse (24. Mai 2017)

@meisterfisch Dann lies dich ein!  Das ist extrem wertvolles Wissen und auf dem Arbeitsmarkt praktisch unerlässlich.

Für den Anfange empfehle ich dir, auf jeden Fall mal SQL zu Coden. Ein Prepared Statement trennt die Struktur des Queries vom Inhalt:


```
INSERT INTO film (name, bewertung) VALUES (?, ?)
```
Zuerst wird der Query so an den DB-Server geschickt. Der erkennt dann die Struktur, die Daten werden separat übertragen. Für die beiden ? kann man dann Werte angeben, z.B. "Film mit' Apostroph im Titel" und 5. Dadurch wird jeglicher Konflikt zwischen der Logik deines Queries und den Daten vermieden.

Wenn du dann mit SQL gut umgehen kannst macht es Sinn, einen O/RM zu verwenden. Das ist aber Zukunftsmusik und macht nur Sinn, wenn man SQL beherrscht.[/CODE]


P.S.:
Was ist denn, wenn ein Filmtitel ein " hat?


----------



## andy82 (29. Mai 2017)

Tobse hat gesagt.:


> ...
> 
> P.S.:
> Was ist denn, wenn ein Filmtitel ein " hat?


'"' = '\"'


----------



## mrBrown (29. Mai 2017)

andy82 hat gesagt.:


> '"' = '\"'


Ich glaube das ist @Tobse bewusst 
Ihm ging es um "normale" gegen Prepared Statements, bei ersteren müsste man (automatisiert) escapen, bei letzteren nicht


----------



## Tobse (29. Mai 2017)

@andy82 @mrBrown Ja, natürlich ist mir das bewusst 

Ich bezog mich dabei auf diese Aussage hier:


meisterfisch hat gesagt.:


> [Beispielsweise wenn eine Beschreibung Anführungsstriche(")hatte, bekam ich im Javaprogram eine Fehlermeldung, weil bei insert selbst Anführungsstriche als Trennzeichen genutzt werden.


Wenn das nämlich der Fall ist, benutzt @meisterfisch 100%ig _keine _Prepared Statements. Und das ist schlecht. Ich verstehe nicht, warum man im Jahre 2017 überhaupt noch jemanden ohne arbeiten lässt. Das Sicherheitsrisiko ist eklatant.


----------



## mrBrown (29. Mai 2017)

Tobse hat gesagt.:


> Ich verstehe nicht, warum man im Jahre 2017 überhaupt noch jemanden ohne arbeiten lässt. Das Sicherheitsrisiko ist eklatant


Ich denke mal, die meisten interessiert es einfach nicht. Das gleiche wie bei Tests und vernünftig strukturiertem Code - einfach hingeklatscht geht halt erstmal schneller, und weiter denken ja die wenigsten


----------



## DrZoidberg (29. Mai 2017)

Eine Datenbank ist natürlich die professionellste Lösung. Ich wollte aber trotzdem noch erwähnen, dass JSON hier auch problemlos funktionieren sollte. Bei nur 10 000 Datensätze wäre eine JSON Datei wahrscheinlich nicht mehr als ein paar MB groß und kann in einem Bruchteil einer Sekunde geladen und geparst werden.


----------



## Thallius (30. Mai 2017)

mrBrown hat gesagt.:


> Ich denke mal, die meisten interessiert es einfach nicht. Das gleiche wie bei Tests und vernünftig strukturiertem Code - einfach hingeklatscht geht halt erstmal schneller, und weiter denken ja die wenigsten



Wenn ich mit JDBC arbeite, dann ist es sicherheitstechnisch extrem egal ob prepared statements nehme oder nicht, da es keine Zwischenschicht gibt wo sich ein MITM reinschleichen kann. Prepared statements sind nur für den Webservice (das Backend) wichtig um die Anfragen die reinkommen zu entschärfen.

Gruß

Claus


----------



## mrBrown (30. Mai 2017)

Thallius hat gesagt.:


> Wenn ich mit JDBC arbeite, dann ist es sicherheitstechnisch extrem egal ob prepared statements nehme oder nicht, da es keine Zwischenschicht gibt wo sich ein MITM reinschleichen kann. Prepared statements sind nur für den Webservice (das Backend) wichtig um die Anfragen die reinkommen zu entschärfen


Du kannst meine Aussage noch um ein "extrem egal" ergänzen


----------



## Tobse (30. Mai 2017)

Thallius hat gesagt.:


> Wenn ich mit JDBC arbeite, dann ist es sicherheitstechnisch extrem egal ob prepared statements nehme oder nicht, da es keine Zwischenschicht gibt wo sich ein MITM reinschleichen kann. Prepared statements sind nur für den Webservice (das Backend) wichtig um die Anfragen die reinkommen zu entschärfen.



Wo soll ich anfangen... ? Prepared Statements benutzt man *überall*, wo Benutzereingaben im Spiel sind. *Überall*. Ich weiss, wenn man weiss, was man macht, geht es auch so, aber Fehler sind Menschlich, oder? Und du willst mir nicht erzählen, dass der obere Code leichter zu lesen + verstehen ist als der untere:


```
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c, d FROM table JOIN table ON table.fk = table2.id AND table2.foo = \"" + escapeSQLValue(table2Foo) + \"" WHERE table.bar = \""+ escapeSQLValue(someOtherTransform(12512) + someOtherInput)) + "\" AND table2.something BETWEEN 0 AND " + Integer.toString(table2Something));
```


```
PreparedStatement stmt = connection.prepareStatement("SELECT a, b, c, d FROM table JOIN table ON table.fk = table2.id AND table2.foo = ? WHERE table.bar = ? AND table2.something BETWEEN 0 AND ?");
stmt.setString(0, table2Foo);
stmt.setString(1, tableBar);
stmt.setInt(2, table2Something);
ResultSet rs = stmt.executeQuery();
```


----------



## JuKu (1. Jun 2017)

Auf jeden Fall eine Datenbank verwenden.
Am besten mit PreparedStatements, dann lernst du es gleich richtig.


----------

