Hi Leute, ich habe einen funktionierenden Webserver mit einer
sql-Datenbank und apache (fertig). Ich habe auch woanders ein Reihe
Sensoren, die per node-red abgefragt werden und Signale liefern (auch
fertig).
Nun möchte ich die Sensordaten an den Webserver schicken und in die
Datenbank schreiben (1), sowie später ein Diagramm daraus machen (2).
Das node-red kann ausgehend ins Internet senden und HTTP-Requests oder
auch websocket-Anfragen generieren.
Meine Frage ist nun, was brauche ich auf dem Server für ein Tool, was
für Werkzeuge empfehlt Ihr? Was ich schonmal vor ewigen Zeiten gemacht
habe, ist ein php-Formular (für Menschen), dass die Formulardaten in
eine Textdatei schreibt. Bisschen programmieren kann ich auch noch. Ich
könnte jetzt wieder so ein Formular bauen und mit dem http-request
aufrufen, in php dann ein sql insert into .. aber das war vor vielen
Jahren, inzwischen gibt es dafür bestimmt geeignetere, einfache kleine
schicke Werkzeuge?
Für (2) habe ich an Chart.js gedacht - aber auch hier die Frage - was
nimmt man da stattdessen besser?
sql_bastler schrieb:> Hi Leute, ich habe einen funktionierenden Webserver mit einer> sql-Datenbank und apache (fertig).
den Teil würde ich wegwerfen, und durch ein fertiges Grafana + Influxdb
"aus der Dose" ersetzen.
node-red kann direkt nach influx-db schreiben.
Ansonsten hätte die db auch einen http-Endpunkt ("/write") mit dem man
recht einfach per HTTP-POST Daten einfügen kann.
Falls du eine alte c't rumliegen hast:
https://www.heise.de/ratgeber/Smart-Home-Messwerte-aufbereiten-mit-Node-Red-und-InfluxDB-4649848.html
ist aber auch so kein Hexenwerk.
Εrnst B. schrieb:> den Teil würde ich wegwerfen
Nein, den brauche ich schon noch, da läuft mein Owncloud drauf und
andere Sachen! :-)
Außerdem ist da ein ordentliches SSL-Zertifikat und TLS/https drauf, das
kann das ein "fertiges" System ja nicht dabei haben - das ist dann
"fertig" ohne Absicherung, oder?
sql_bastler schrieb:> Für (2) habe ich an Chart.js gedacht - aber auch hier die Frage - was> nimmt man da stattdessen besser?
Apache als Reverse-Proxy und Grafana.
Also gut, ich hätte dazuschreiben sollen, dass das Diagramm dann im
Internet zu sehen sein soll, und dass mir nicht die ganze Welt sinnlose
Daten in meine Datenbank füttern soll.. Also ein bisschen Abgesichert
sollte es schon sein.
Naja Du wirst es doch wohl hinbekommen, Deine Daten mit irgendwas zu
verschlüsseln und dabei ein Kennwort mitzuschicken. Oder mit dem
Kennwort verschlüsseln wenn Du feststellen kannst, ob die
Entschlüsselung erfolgreich war oder nicht. Mit POST Requests kannst Du
ja direkte Binärdaten schicken, die dabei herauskommen, das sollte ja
nicht stören.
Ich würde sowas immer noch mit PHP lösen, damit kann man die Requests
entgegennehmen, in eine MySQL-Datenbank schreiben und auch die Diagramme
zeichnen.
Ben B. schrieb:> Ich würde sowas immer noch mit PHP lösen, damit kann man die Requests> entgegennehmen, in eine MySQL-Datenbank schreiben und auch die Diagramme> zeichnen.
Ja, Ben, das würdest Du wahrscheinlich so machen, weil Du wie so viele
(auch professionelle) Entwickler nicht weißt, daß Relationale
Datenbanken für sowas nicht besonders geeignet sind und es viel bessere
Möglichkeiten dafür gibt.
Alle klassischen Relationalen Datenbanken geben gewisse Garantien, und
das hat Kosten. Sie sind auch nicht besonders gut darin, mit Zeitserien
umzugehen, was bei Sensordaten und Logdateien die Regel sein dürfte. Da
gibt es viel besser geeignete Spezialisten, zum Beispiel Prometheus,
InfluxDB oder Elasticsearch. Auch moderne NoSQL-Datenbanken wie MongoDB,
CouchDB, Apache Solr oder Apache Cassandra kommen mit gewissen
Abstrichen in Frage. Und wenn die Daten über gewisse Zeiträume gehalten
und dabei immer weiter aggregiert werden sollen,
Alle diese Lösungen können mit Zeitseriendaten viel besser umgehen, im
Sinne von: schneller, mit weniger Ressourcen- und Verwaltungsaufwand,
und sie sind für Clients einfacher zu nutzen, ohne Gehassel mit
SQL-Queries oder ORM.
könnte auch das gute alte rrdtool genutzt werden.
Auch für die Visualisierung solcher Daten gibt es bereits fertige
Werkzeuge, die direkt auf die genannten Datenbanksysteme zugreifen
können, ohne zuerst die Daten auslesen und womöglich transformieren und
aggregieren zu müssen, damit irgendeine JavaScript-Library sie lesen
kann. Grafana und Graphite sind -- aus guten Gründen -- sehr beliebt,
für Elasticsearch gibt Kibana, nur um einige Beispiele zu nennen. Da muß
man schon lange nicht mehr selbst etwas basteln, sondern kann auf
fertige Software zurückgreifen, ohne Not-invented here-Probleme,
Wartungs-, Pflege- und Erweiterungsaufwände.
Es gibt Gründe, warum die langjährige Vorherrschaft Relationaler
Datenbanken in den letzten Jahren immer stärker zu bröckeln beginnt. Und
wenn jemand mit Daten umgehen muß, dann sollte er langsam mal über
seinen Tellerrand hinaus schauen, was für tolle Sachen die moderne Welt
zu bieten hat.
Welch Zufall ich stehe aktuell vor dem selben Problem.
Ich habe aktuell auch sowas zusammengeschustert. Erst sparkline-plugin,
naja zu rudimentär, für den Anfang ok aber dann will man schnell mehr.
Also nach richtiger Graphendarstellung gesucht:
GraphJS probiert, schon besser aber es fehlt zu viel, es mal halt nur
Diagramme, den Rest muss man selber ranflicken. Könnte ich habe aber
noch 1000 andere Dinge in der Pipeline.
Also noch andere Visualisirungshelfer gesucht:
d3.js, jqPlot,... alles der selbe Kram. Da fehlt einfach das Drumherum.
Man will früher oder später umfangreiche Filter, dahsboardartige
Darstellung, das Grafanzeug sieht schon sehr geil aus und bringt viel
mit.
Ich bin zwar kein Freund von diesem NoSQL-Zoo aber eines muss man denen
lassen, das Zeug ist für den Bereich praktisch Standard, die Frontends
wie Grafana oder was es dazu sonst so gibt sieht um Welten besser aus
als man das selber zurechtfrickelt und hat alles was man typsicherweise
haben will.
Da muss man "Jemand" einfach recht geben, ich hab es selber nicht
wahrhaben wollen und das "selber schnell was zurechtstricken" bleiben
lassen.
Aktuell bin ich da noch am informieren, "Jemand" hat ja schon einiges
genannt, was ich selber auch noch nicht kannte, Danke dafür an "Jemand".
Jemand schrieb:> Alle klassischen Relationalen Datenbanken geben gewisse Garantien, und> das hat Kosten. Sie sind auch nicht besonders gut darin, mit Zeitserien> umzugehen, was bei Sensordaten und Logdateien die Regel sein dürfte. Da> gibt es viel besser geeignete Spezialisten, zum Beispiel Prometheus,> InfluxDB oder Elasticsearch.
Also danke Jemand für die genannten Tools, ein guter Überblick, das
werde ich mir ansehen. Aber für die Installation von mySQL/MariaDB
musste ich weder was extra tun noch zahlen, ich brauch sie sowieso und
hab sie schon durch OwnCloud. SQL ist wie HTML schon Jahrzehnte alt und
bewährt, mal sehen ob in 10 Jahren, wenn ich mein heutiges System mal
warten muss, noch einer "CouchDB" kennt. Und über die paar 10.000
Datensätze, die bei mir zusammenkommen, wird jede DB vor Lachen kaum in
den Schlaf finden. Also etwas mehr Respekt vor den Altgedienten bitte
;-)
sql_bastler schrieb:> Also danke Jemand für die genannten Tools, ein guter Überblick, das> werde ich mir ansehen.
Nun bin ich zwar nicht "Jemand", aber was er schreibt, hat mir gut
gefallen. Nicht zuletzt auch, weil es sich mit meinen Erfahrungen deckt.
> Aber für die Installation von mySQL/MariaDB musste ich weder was extra> tun noch zahlen, ich brauch sie sowieso und hab sie schon durch> OwnCloud.
Klar. Aus meiner eigenen Erfahrung ist es aber leider so, daß wir alle
eine gewisse Neigung zum berühmt-berüchtigten Hammer-Nagel-Problem
haben: wenn wir nur unseren Hammer haben, sieht jedes Problem wie ein
Nagel aus.
> SQL ist wie HTML schon Jahrzehnte alt und bewährt, mal sehen ob in 10> Jahren, wenn ich mein heutiges System mal warten muss, noch einer> "CouchDB" kennt. Und über die paar 10.000 Datensätze, die bei mir> zusammenkommen, wird jede DB vor Lachen kaum in den Schlaf finden.LOL Ja, damit hast Du gleichzeitig Recht und Unrecht. Denn jetzt hast
Du schon eine je nach Nutzerzahlen und Nutzungsprofilen womöglich
durchaus belastete DB, und möchtest da jetzt zusätzlich noch eine
weitere Applikation draufpacken. Und dann noch eine, noch eine, und...
genau.
Und dann kommt diese... Sache mit den Queries. Daten eindampfen,
aggregieren, in eine saubere Form bringen, damit Dein selbstgestricktes
Webfrontend sie sauber verarbeiten und visualisieren kann. Wieder neue
Last auf der DB, die muß jetzt auf einmal obendrein rechnen. Ach nein,
muß sie nicht, das machst Du alles in Deinen Anwendungen? Ja, das hab'
ich auch mal gedacht... all das.
> Also etwas mehr Respekt vor den Altgedienten bitte ;-)
Sei mir bitte nicht böse, aber ich hab' schon ein paar Jahre mit diesen
Kompjutern hinter mir, und das "Altgediente" kann mich mittlerweile mal
ganz gepflegt dort, wo die Sonne nicht scheint. Ich bin 'raus aus dieser
Art von Meritokratie, sonst würde ich heute noch in BASIC und Assembler
meine eigenen Datenbanken programmieren, wie zur Zeit von Mammuts und
Mastodons.
Aber ich bin mittlerweile auch gereift genug, um über meinen Tellerrand
hinaus zu schauen, und das Gras auf der Wiese am anderen Flußufer IST
grüner. Man glaubt es kaum, aber Paradigmen, Technologien, Denkweisen
entwickeln sich weiter, wenn man offen ist und sich darauf einläßt.
Das hast Du ja sogar im SQL-Umfeld. Weißt Du, was Windowfunctions sind?
Binning auf Zeitserien ist insbesondere mit SQL eine widerwärtige
Krankheit, und wird es auch bleiben. Mit modernen Technologien ist das
so einfach und elegant...
Wobei, es ist (und bleibt) natürlich Deine Wahl. Ich kann Dir nur sagen:
guck mal, ob man Deine Anforderungen nicht viel einfacher, schneller und
eleganter umsetzen kann. Ob Du dann guckst oder nicht, ist und bleibt
Deine Sache. Alles gut.
Ich werd mich an dem Streit über Datenbankformate jetzt nicht
beteiligen. Nur insoweit, daß man bei dem neuen Kram nie weiß wie lange
es sich hält bzw. wann der Support dafür schwindet. Bei MySQL kann ich
mir sehr sicher sein, daß das auch weitere Jahrzehnte überlebt. Ob man
damit nun irgendwelche Zeitfunktionen mehr oder weniger schlecht
hinbekommt ... wer weiß, das könnte auch ein Problem des Ansatzes bzw.
der Programmierung durch den Anwender sein.
> wenn wir nur unseren Hammer haben,> sieht jedes Problem wie ein Nagel aus.
Aber es funktioniert gut. Genau wie Kanone->Spatz, der ist danach
definitiv hin. Machen die Amis seit Jahrzehnten so. Wenn sie irgendwo
ein Problem haben, Bombe drauf und gut.
Ben B. schrieb:> Aber es funktioniert gut. Genau wie Kanone->Spatz,
Um in dem Bild zu bleiben: Das Problem ist eine schnell anfliegende MIG,
deine "MySQL-Kanone" ist ein Sturmgewehr. Klar, das Sturmgewehr kann
viele Probleme lösen, aber das aktuelle nur mit viel Glück und Können.
Schau lieber ein paar Meter weiter, da steht eine Batterie kostenlos
nutzbarer "NoSQL-Boden-Luft" Raketen, die das Ziel bereits erfasst
haben, du musst nur den Abzug betätigen.
Ben B. schrieb:> daß man bei dem neuen Kram nie weiß wie lange> es sich hält
Oder: Man kann zwei Metallteile immer mit Klebstoff verbinden.
Panzertape gibt es schon ewig, und wird es sicher auch noch lange geben.
Warum also mit "Löten", "Schweißen" und anderem Hipster-Kram
beschäftigen?
Leute ihr quatscht beim Thema welche DB mal wieder gnadenlos aneinander
vorbei. Die Vorteile der NoSQL-DBs fürs Sensordaten sammeln ergeben sich
doch erst bei sehr grossen Datenmengen, welches Datenaufkommen der
Threaderöffner hat weiss nur er und wenn er MySQL schon einsetzt und das
für geeignet hält dann macht er das eben so. Ich werde mir auch keine
NoSQL-DB für ein paar Sensordaten ans Bein binden, ich habe dadurch
keine Vorteile eher Nachteile: Einarbeiten in ein neues DB-System,
zusätzlicher Wartungs und Pflegeaufwand. Das ist schlicht überflüssig
und das Argument Performancevorteil ist auch keines bei den lächerlichen
Datenaufkommen.
Ben B. schrieb:> Ich weiß es nicht genau, aber ich würde stark vermuten> schweißen/schmieden ist älter als Panzertape.
aber nicht als "Kleben" als solches. :)
"SQL" ist auch älter als "MySQL" oder "MariaDB".
Und "MySQL" ist ein wenig älter als "RRDtool".
Krapfenzüchter schrieb:> Ich werde mir auch keine> NoSQL-DB für ein paar Sensordaten ans Bein binden, ich habe dadurch> keine Vorteile eher Nachteile: Einarbeiten in ein neues DB-System,> zusätzlicher Wartungs und Pflegeaufwand.
Genau das ist andersherum.
bei der MySQL-DB musst du das alles von Hand machen, die Tabellen
definieren, Code schreiben der die Daten einspeist, ausliest,
visualisiert.
Influx/Grafana starte ich, trags (reverse-proxy) in die apache-config
ein, bastel die db-connection klicki-bunti ins node-red, und stöpsel mir
klicki-bunti ein paar Graphen zusammen, die ich dann in eine Webseite
einbetten kann.
Der TE sucht ein "Tool" was er verwenden kann, und will keins von der
Pike auf neu entwickeln. Vor allem weil er nur ein "Bisschen
programmieren" kann. Da kann man die PHP-SQL-Injection-Lücke praktisch
schon riechen.
Oder würdest du ihm von Owncloud abraten, weil man ja alles selber mit
mysql und PHP machen kann? Und das dann weniger
Entwicklungs-/Wartungs-/Pflegeaufwand ist, als eine fix-und-fertige
owncloud-installation?
Krapfenzüchter schrieb:> vorbei. Die Vorteile der NoSQL-DBs fürs Sensordaten sammeln ergeben sich> doch erst bei sehr grossen Datenmengen, welches Datenaufkommen der
Nein, die Vorteile sind bei einer NoSql sind halt, das es kein festes
Schema braucht.
Gruß Ingo
Bei Zeitbasierten Daten ist aber schon ein Teil als Schema vorgegeben:
die Zeitachse und damit eine timestamp Spalte. Und mit diesem Wissen
über die Daten können die TDBMS die Datenorganisation und die Zugriffe
optimieren.
InfluxDB hat auch eine SQL ähnliche Abfragesyntax, da muss man nicht
viel dazulernen. Und wenn so eine DB kontinuierlich mit Daten gefüllt
wird, dann können schon große Mengen zusammenkommen.
Ingo D. schrieb:> Nein, die Vorteile sind bei einer NoSql sind halt, das es kein festes> Schema braucht.
Ist doch lächerlich das als Argument aufzuführen. Man hat ne Tabelle und
schreibt die Uhrzeit + Messdaten rein. Meinetwegen pro Sensor eine
eigene Tabelle, trivialer gehts doch gar nicht, nicht mal ne Relation
vorhanden.
Wenn MySQL eh schon für was anderes genutzt wird erschlägt man diese
lächerliche Furzanwendung Messdaten sammeln damit auch.
Zum Thema Sicherheit, wenn er eh schon MySQL verwendet kennt er
vermutlich auch die Fallen und entwickelt schon länger entsprechend. Das
NoSQL-Gerümpel ist in der Vergangeheit schon öfters durch krasse Lücken
aufgefallen (massenhaft ungesicherte CouchDBs, siehe heise.de), deren
Lücken und Stolperfallen sind eher wenigen bekannt und auch schlechter
dokumentiert, tut doch nicht so als wäre das Zeug per Defnition sicher.
Das missionarische Gehabe das hier wieder an den Tag gelegt wird ist
einfach lächerlich.
Johannes S. schrieb:> Bei Zeitbasierten Daten ist aber schon ein Teil als Schema> vorgegeben:> die Zeitachse und damit eine timestamp Spalte. Und mit diesem Wissen> über die Daten können die TDBMS die Datenorganisation und die Zugriffe> optimieren.
Solche Furzanforderungen optimiert dir auch jede SQL von Haus aus. Und
selbst wenn die messbar langsamer ist, von welchen Werten bei welchen
Datenmengen reden wir hier überhaupt. Das ist reines Posergeschwafel was
hier abgesondert wird ohne die konkreten Anforderungen zu kennen.
Die NoSQL-DB ist da erst bei sehr grossen Datenmengen im Vorteil, eure
Pseudoargumente stechen alle nicht bei kleineren Anwendungen.
Das ist eine reine Schwanzlängendiskussion fernab von der Realität.
Krapfenzüchter schrieb:>Das missionarische Gehabe das hier wieder an den Tag gelegt wird ist>einfach lächerlich.
.. ich habe eher das Gefühl Du willst hier missionieren ....
>Meinetwegen pro Sensor eine>eigene Tabelle, trivialer gehts doch gar nicht, nicht mal ne Relation>vorhanden.
Genau, das nenn ich mal optimal ;-)
Na, Ok, mach Du mal mit Deiner SQL-DB weiter, ich nutze für meine
Sensoren eine InfluxDb. Wenn ein ein neuer Sesnsor hinzukommt schreibe
ich das halt einfach in die Json-Strucktur und gut ist ....
Wie war das mit dem Hammer / Nagel Problem .. wenn man nur den Hammer
kennt ....
> Da kann man die PHP-SQL-Injection-Lücke praktisch schon riechen.
In dieser Anwendung einfach keine externen Strings (aus Links etc.) an
die DB senden, dann hat man dieses Problem vom Tisch.
Ben B. schrieb:> Ich werd mich an dem Streit über Datenbankformate jetzt nicht> beteiligen. Nur insoweit, daß man bei dem neuen Kram nie weiß wie lange> es sich hält bzw. wann der Support dafür schwindet. Bei MySQL kann ich> mir sehr sicher sein, daß das auch weitere Jahrzehnte überlebt.
Jaaa.... und schon da wäre ich ein bisschen unsicher. Du weißt schon,
daß MySQL (nicht die Forks, sondern MySQL selbst) mittlerweile einem
großen Konzern namens Oracle gehört? Einem Konzern, der eine eigene
Datenbank-Engine im Angebot hat und sich bisher... sagen wir: nicht
durch besondere Nutzerfreundlichkeit auszeichnet.
Larry muß ja seine Yachten bezahlen, ne...?
Weißt Du, wenn man mal ein bisschen über den eigenen Tellerrand schauen
würde, dann fiele einem schnell auf, was Oracle zum Beispiel gerade mit
Java veranstaltet. Aber man kann das natürlich auch lassen...
Nebenbei bemerkt: meine Erfahrungen mit MySQL 3.23 waren so desaströs,
daß ich die Software aus dieser Feder niemals nie nicht wieder benutzen
werde. Wenn Kunden ein OpenSource-RDBMS haben wollen, dann empfehle ich
immer zuerst PostgreSQL.
> Ob man damit nun irgendwelche Zeitfunktionen mehr oder weniger schlecht> hinbekommt ...
... spielt für Entwickler tatsächlich eine Rolle...
>> wenn wir nur unseren Hammer haben,>> sieht jedes Problem wie ein Nagel aus.> Aber es funktioniert gut.
Für diese Art von Daten eben nicht.
> Machen die Amis seit Jahrzehnten so. Wenn sie irgendwo> ein Problem haben, Bombe drauf und gut.
Ich möchte mich ungern auf politische Diskussionen einlassen, aber das
ist keine auch nur ansatzweise kluge Aussage.
Krapfenzüchter schrieb:> Leute ihr quatscht beim Thema welche DB mal wieder gnadenlos aneinander> vorbei. Die Vorteile der NoSQL-DBs fürs Sensordaten sammeln ergeben sich> doch erst bei sehr grossen Datenmengen, welches Datenaufkommen der> Threaderöffner hat weiss nur er und wenn er MySQL schon einsetzt und das> für geeignet hält dann macht er das eben so. Ich werde mir auch keine> NoSQL-DB für ein paar Sensordaten ans Bein binden, ich habe dadurch> keine Vorteile eher Nachteile: Einarbeiten in ein neues DB-System,> zusätzlicher Wartungs und Pflegeaufwand. Das ist schlicht überflüssig> und das Argument Performancevorteil ist auch keines bei den lächerlichen> Datenaufkommen.
Vielen Dank für Deinen Beitrag. Aber ich fürchte, er geht komplett an
der Sache vorbei.
Ich erkläre das jetzt mal an einem Beispiel.
Schau, mein Freund, nennen wir ihn Jörn (the names have been changed to
protect the innocent) beherrscht MySQL und PHP. Das heißt: er hat sich
da hineingearbeitet, mit Herzblut, Motivation, und Engagement. Er kann
mit dieser Kombination alles machen, was ihm begegnet, und bitte glaub'
mir: er ist wirklich gut mit seinem Zeug.
Das Dumme ist: seine ersten Erfahrungen mit Programmierung und
Datenbanken waren so herausfordernd, daß er sie nicht nochmal machen
will. Sein Denkfehler ist: wenn Du eine Sprache gelernt hast, kannst Du
die meisten. Wenn Du eine Datenbank erlernst, kannst Du die anderen
auch.
Und wenn Du das Prinzip von Datenbanken verstanden hast, kannst Du die
richtige Datenbank für Deine Aufgabe nutzen.
Krapfenzüchter schrieb:> Ingo D. schrieb:>> Nein, die Vorteile sind bei einer NoSql sind halt, das es kein festes>> Schema braucht.> Ist doch lächerlich das als Argument aufzuführen.
Eigentlich nicht. Denn das Lustige ist: bei vielen NoSQL-Datenbanken
kann ich Schemata mehr oder weniger hart durchsetzen. Wenn man keine
Ahnung hat, einfach mal... ;-)
> Du weißt schon, daß MySQL (nicht die Forks, sondern MySQL selbst)> mittlerweile einem großen Konzern namens Oracle gehört?
Weiß ich - und es ist mir so lange egal wie die eine brauchbare Version
kostenfrei anbieten, die von so gut wie allen Server-Anbietern
unterstützt wird.
Falls Dir das nicht passt, kannst Du ja MariaDB verwenden - dahinter
stecken die ursprünglichen Entwickler von MySQL.
Was mich bei Datenbanken generell stört ist die heute eher kurze
Produktlebensdauer. Damit meine ich nicht Sicherheitsupdates, sondern
gefühlt alle fünf Minuten kommt irgendwas neues, was zum alten nicht
mehr vollständig kompatibel ist, was eher früher als später zu Problemen
führt. Kommt mir vor wie eine Arbeitsbeschaffungsmaßnahme für
Web-Entwickler, die dadurch ständig ihre Projekte auf neue Versionen
oder andere DBs migrieren dürfen.
Ben B. schrieb:> Weiß ich - und es ist mir so lange egal wie die eine brauchbare Version> kostenfrei anbieten, die von so gut wie allen Server-Anbietern> unterstützt wird.
Kann man so sehen, klar, muß man aber nicht.
> Falls Dir das nicht passt, kannst Du ja MariaDB verwenden - dahinter> stecken die ursprünglichen Entwickler von MySQL.
Das ist diesseits bekannt. Aber wenn Du meinen Beitrag etwas
aufmerksamer gelesen hättest, wäre Dir sicherlich aufgefallen, daß ich
meine Datenbank der Wahl bereits erwähnt habe. Sie heißt PostgreSQL.
Für unseren Stats Server habe ich damals per Python auf den Gameservern
HTTP POSTs mit XML zusamengestellt, mit Passwort versehen und sie an den
Stats Server an ein PHP Skript geschickt. Auch bei dem lief schon mySQL
und die PHP Unterstützung für mySQL und XML war ja schon fertig da.
Nur noch die Payload auseinanderpflücken und auf die DB schreiben.
