Forum: PC-Programmierung Daten an einen Webserver schicken, in db speichern und Diagramm draus machen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von sql_bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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.

von sql_bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ε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?

von 100Ω W. (tr0ll) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von sql_bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Heinz R. (heijz)


Bewertung
0 lesenswert
nicht lesenswert
Nicht genau was Du suchst, aber wen Du Deine ANforderungen etwas anpasst 
vielleicht genau das Richtige:

 https://volkszaehler.org/

von Jemand (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Krapfenzüchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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".

von sql_bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
Ich weiß es nicht genau, aber ich würde stark vermuten
schweißen/schmieden ist älter als Panzertape.

von Krapfenzüchter (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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".

von Εrnst B. (ernst)


Bewertung
2 lesenswert
nicht lesenswert
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?

von Ingo D. (ingo2011)


Bewertung
1 lesenswert
nicht lesenswert
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

von Johannes S. (jojos)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Krapfenzüchter (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Krapfenzüchter (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Ingo D. (ingo2011)


Bewertung
3 lesenswert
nicht lesenswert
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 ....

von Pete K. (pete77)


Bewertung
-1 lesenswert
nicht lesenswert
Für selbst gemachte Visualisierung habe ich auch schon einmal highcharts 
genommen.
https://www.highcharts.com/

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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... ;-)

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.