MySQL Json String in MySQL einfügen.

[XHann3sX]

Hallo,

ich wollte heute etwas an einem Programm schreiben und müsste hierzeu einen JSONArray als JSON String in eine MySQL schreiben, da MySQL anscheinend JSON unterstützt dachte ich, das das gehen würde. Nun habe ich eine

    Connection connection;
connection = DriverManager.getConnection(xxx);
connection.createStatement().execute("INSERT INTO xxx(json_String) VALUES("+json+")");

Nunja jetzt schmeißt ehr mir einen Syntax-Fehler im JSON-String raus, da ich denke er meint dass die Kommas die in diesem JSON-String vorhanden sind als einzelne Werte ansieht , kann das sein ? Kann ich ein SQL Statement noch anders ausführen ?

Hannes

 

[Tobse]

Benutze PreparedStatements. Undzwar immer! Wenn du Queries so ausführst, wie oben beschrieben, hast du eine klaffende Sicherheitslücke. Was wäre, wenn jemand in die Variable json diesen String hinein bekäme?

'{}'); DROP TABLE users;#

Setz es mal ein und schau was aus deinem harmlosen INSERT geworden ist 😉

Das nennt sich dann eine SQL Injection. Etliche der berühmtesten Hacks wurden über derartige Lücken ausgeführt.

----
Prepared Statements beheben dieses Problem. Siehe hier die offizielle Doku für Java (Prepared Statements funktionieren mit allen möglichen Programmiersprachen).

----
JSON ist am Ende auch nur ein String; du kannst JSON in jede VARCHAR oder TEXT Spalte schreiben, ist ja nur Text. Da bekommst du aber keine zusätzlichen Features; die bekommt man erst mit dem JSON Datentyp.

 

[XHann3sX]

Danke für den Tipp werde dann absofort PreparedStatements nutzen , jetzt klappt alles , Danke 😉

 

[Thallius]

Nur aus Interesse. Was macht es für einen Sinn ein JSON in eine DB zu speichern?

 

[XHann3sX]

Naja ich habe ein Array an Objekten, die alle unterschiedlich aufgebaut sind also Attribute haben , die nicht jedes andere hat, und auch ist die Zahl der Objekte nicht immer festgelegt, da kann ich dann einfach diese als JSON serialisieren und bei Bedarf deserialiesieren .
Es gibt ja auch Datenbanken, wie MongoDB , die ausschließlich auf JSON ähnlichen Einträgen basieren, gefällt mir persönlich auch besser, vlt auch nur weil ich sie das letzte Jahr über nur benutzt habe 😀

 

[Thallius]

Also ich finde Datenbanken nur dann sinnvoll wenn die Datenbank selber mir hilft die Daten zu finden und zu lesen die ich brauche. Wenn die Datenbank die Daten selber nicht kennt ist das nicht Möglich. Ich benutze die Datenbank dann also nur als Speichermedium. Das birgt gegenüber einer Textdatei dann aber keinen Vorteil mehr.

Guss

Claus

 

[tommysenf]

Das birgt gegenüber einer Textdatei dann aber keinen Vorteil mehr.

Naja, Clustering, Nachhing oder ACID würde ich schon als Vorteile sehen. Des Weiteren besitzt MySQL ja auch einen internen JSON Datentyp auf dem sich mit den JSON Daten performant arbeiten lässt.

 

[XHann3sX]

Deswegen muss ich ja nicht nur eine JSON speichern, da kommen noch diverse ID von Benutzern eine allgemeine ID Timestamp etc , da fällt vorallem Macher das rausqueryen leichter 😀

 

[Tobse]

@Thallius genau das ist ja der Trick beim JSON Support von MySQL:

# von https://dev.mysql.com/doc/refman/5.7/en/json.html
mysql> SELECT JSON_EXTRACT('{"id": 14, "name": "Aztalan"}', '$.name');
+---------------------------------------------------------+
| JSON_EXTRACT('{"id": 14, "name": "Aztalan"}', '$.name') |
+---------------------------------------------------------+
| "Aztalan"                                               |
+---------------------------------------------------------+

Ich bin auch ein Freund der Normalisierung. Aber Normalisierte Daten wollen auch von einem Datenformat zu einem anderen migriert werden. Ich habe den JSON-Datentyp neulich in diesem Szenario verwendet: die Anwendung ist ein Front-End für eine Backend-Schnittstelle, die der Kunde bei sich pflegt und bereitstellt. An diese Schnittstelle kann man komplexe Anfragen senden und erhält eine komplexe Antwort. Für eine Historie der gestellten Anfragen werden die Antworten als JSON abgelegt. Die müssen nie bis selten durchsucht werden; gleichzeitig hält es aber den Aufwand bei einer Änderung der Datenstruktur in der Antwort gering, weil das Front-End nicht die komplette Anfragehistorie migrieren muss (was ggf. auch garnicht ginge, wenn. z.B. Felder dazukommen).

 

[JuKu]

Normalisierung ist meist sehr unperformant.
Aber für den Thread Ersteller wäre eine NoSQL-Datenbank viel sinnvoller, als eine relationale Datenbank mit fester Struktur.
Deine Daten haben eben keine feste Struktur, wie du selbst sagst.

 

[Thallius]

Normalisierung ist meist sehr unperformant.

DA hast du aber irgendwas an der Normalisierung nicht verstanden...

 

[mrBrown]

DA hast du aber irgendwas an der Normalisierung nicht verstanden...

Nö, da hat er abhängig vom Usecase schon Recht. Normalisierung erfordert Joins beim Lesen, ohne braucht man die nicht

 

[XHann3sX]

Aber für den Thread Ersteller wäre eine NoSQL-Datenbank viel sinnvoller, als eine relationale Datenbank mit fester Struktur.

Ja, mir wäre hierfür auch eine MongoDB oderso lieber gewesen , aber da das Programm auf einem bereits existierenden Server läuft, wo bereits alle Programme MySQL nutzen wäre es nicht sehr ist es vom Betreiber nicht gewollt, aber da die Daten echt nur im seltensten Fällen ausgelesen werden , sollte das nicht gravierend sein

 

[JuKu]

DA hast du aber irgendwas an der Normalisierung nicht verstanden...

Wie mrBrown bereits sagte, brauchst du dann JOINs.
Allerdings kosten JOINs extrem viel Performance, weshalb man in der Praxis lieber auf Normalisierung verzichtet.
Noch teurer sind Abhängigkeiten (Fremdschlüssel usw.).
Manchmal werden sogar Daten deshalb redundant gespeichert, um Abfrage Queries & JOINs zu sparen, diesen Weg gehen z.B. Google oder Facebook. Aber für Big Data sind relationale Datenbanken eh nur bedingt geeignet.

 

[Meniskusschaden]

Allerdings kosten JOINs extrem viel Performance, weshalb man in der Praxis lieber auf Normalisierung verzichtet.

Natürlich kosten JOINs Performance. Ob es extrem viel ist, hängt vermutlich davon ab, was man unter extrem versteht. Jedenfalls ist es nicht so viel, dass man deswegen auf Normalisierung verzichten würde. Für die allermeisten Unternehmen dürften deren ERP- oder Warenwirtschaftssysteme das Rückgrat ihrer Organisation bilden. Natürlich wird da normalisiert. Es gibt jede Menge IT jenseits von BigData.

 

[mrBrown]

Jedenfalls ist es nicht so viel, dass man deswegen auf Normalisierung verzichten würde.

Doch, das ist einer der Gründe.

Natürlich macht man das jetzt nicht in jeder Kundendatenbank, hat ja auch niemand behauptet.

 

[Meniskusschaden]

Die Aussage von @JuKu habe ich schon als generelle Empfehlung aufgefasst. Für normale betriebliche Informationssystem würde ich es aber eben anders herum empfehlen: Grundsätzlich normalisieren, es sei denn, es wird zu teuer. In dem Fall verzichtet man dann tatsächlich deswegen - aber eben nicht grundsätzlich. Verzichten ist vielleicht auch nicht ganz treffend, weil es sich häufig so darstellen dürfte, dass man normalisierte Grunddaten auf Transaktionebene hat und aus Performancegründen zusätzlich denormalisierte Aggregationen.

 

[Thallius]

Ich möchte echt gerne mal wissen mit was ihr hier alles so arbeitet wenn ihr so einen Unsinn erzählt. Ich arbeite täglich mit Datenbanken mit 6 stelligen Zeilenzahlen und joine teilweise bis zu 10-15 Tabellen dazu. Trotzdem dauert keiner meiner Queries mehr als 2-400ms.

Und jetzt komm mir bitte keiner mit "Das sind ja auch keine großen Zahlen". Ich finde ein Kudenstamm von ca. 20000 Kunden mit über 100000 Systemen nur in .de nicht wirklich klein.

Gruß

Claus

 

[mrBrown]

Ich möchte echt gerne mal wissen mit was ihr hier alles so arbeitet wenn ihr so einen Unsinn erzählt. Ich arbeite täglich mit Datenbanken mit 6 stelligen Zeilenzahlen und joine teilweise bis zu 10-15 Tabellen dazu. Trotzdem dauert keiner meiner Queries mehr als 2-400ms.

Und jetzt komm mir bitte keiner mit "Das sind ja auch keine großen Zahlen". Ich finde ein Kudenstamm von ca. 20000 Kunden mit über 100000 Systemen nur in .de nicht wirklich klein.

'Ich hab das Problem nicht, also gibt es das nicht' - was ist das denn für eine Einstellung?

Ernstgemeine Frage, ohne dich angreifen zu wollen: Verstehst du nicht, warum Normalisierung schlecht für die Performance sein kann oder hältst du den Unterschied einfach für Irrelevant?

 

[Thallius]

'Ich hab das Problem nicht, also gibt es das nicht' - was ist das denn für eine Einstellung?

Ernstgemeine Frage, ohne dich angreifen zu wollen: Verstehst du nicht, warum Normalisierung schlecht für die Performance sein kann oder hältst du den Unterschied einfach für Irrelevant?

Ich halte die Geschwindigkeit die eine DB braucht um ein JOIN über eine vernünftig Indizierte Tabelle machen für komplett irrelevant, im Gegenzug zu der Zeit die z.B ein SOAP Webservice zum en- und decoden der Daten braucht.

Heutzutage wird überall Performance verschwendet das einem schwindelig wird. Man benutzt Java Spring als Backend (geht es eigentlich noch inperformanter?), Angular JS oder brutal große Frameworks wie Laravel oder Symphonie als frontend und dann will man Geschwindigkeit verbessern indem man die DB nicht normalisiert. Das ist vollkommen krank.

 

[JuKu]

Eine Kette ist nur so stark, wie ihr schwächstes Glied.
Wenn man also Java Spring verwendet, ist die Performance sowieso schon nicht beste. Aber das gehört jetzt nicht in dieses Thema.

@Thallius:
Ganz ehrlich: 6 stellige Zeilenanzahlen in der ganzen Datenbank sind nicht viel. Aber es hat auch gar keiner hier behauptet, dass der Thread Ersteller alles Denormalisieren soll! Wir haben lediglich gesagt, dass JOINS wesentlich unperformanter sind, als denormalisierte Datenbanken. Nicht mehr und nicht weniger.
Wir weichen hier einfach viel zu stark vom Thema ab.

15 JOINs sind echt schon sehr extrem... Sobald ihr mehr Kunden bekommt, skaliert das irgendwann gar nicht mehr gut mit. Und ihr habt damit auch nur die Möglichkeit von Scaling Up, Scaling Out (Datenbank Cluster) würde euch bei so vielen Abhängigkeiten kaum noch Geschwindigkeitsvorteile bringen.

Und btw, 400ms für ein Query ist vieeel zu viel! Eine Webseite sollte im Optimalfall in <400ms ausgeliefert sein, weil noch HTTP Overhead, Verschlüsselung usw. dazu kommt. Wenn man da schon 400ms für die Datenbank bzw. 1 Query verschwendet, dauert so ein Seitenaufbau irgendwann 3 Sekunden - viel zu viel! Schon einen Seitenaufbau von 1 Sekunde empfinde ich persönlich als lästig.
Und Google straft solche langsam Seiten auch deutlich im Suchranking ab (Stichwort SEO, siehe https://developers.google.com/speed/pagespeed/).
Ich selbst versuche immer, dass meine PHP CMS Systeme, die ich geschrieben habe, die Seiten in 200 - 300ms komplett ausliefern (inkl. aller kompletten MySQL Queries, Template Engine, GZip Kompression, usw.).
Bei einem Unternehmen wird aber anders priorisiert, da der Mitarbeiter eh gezwungen ist, seinen Job zu machen, ist es ihm wurscht, ob er 3 Sekunden länger wartet oder nicht. Einem User in der freien Wildbahn würde es allerdings auffallen und es als nervig empfinden.