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.
Nicht genau was Du suchst, aber wen Du Deine ANforderungen etwas anpasst vielleicht genau das Richtige: https://volkszaehler.org/
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?
Ich weiß es nicht genau, aber ich würde stark vermuten schweißen/schmieden ist älter als Panzertape.
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 ....
Für selbst gemachte Visualisierung habe ich auch schon einmal highcharts genommen. https://www.highcharts.com/
> 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.