[MariaDB] Update-Trigger der die selbe Tabelle updaten soll

[Medium]

Moin!

Ich habe eine Tabelle mit Daten zu Rohstofftanks. Ich möchte nun einen "virtuellen" Tank einfügen, der eine Untergruppe der anderen Tanks als Eins wiederspiegeln soll. Insbesondere den Kombinierten Füllstand. Da wäre an sich ein Trigger ja eine schöne Sache. Leider habe ich das Problem, dass ich den u.s. Trigger zwar erzeugen kann, bei einem UPDATE auf die Tabelle gibt's aber Mecker, weil der Trigger seine eigene Tabelle updaten will. Dass das an sich problematisch ist, leuchtet mir grundsätzlich ein. Durch meinen Code wird zwar sichergestellt, dass es zu keinem Konflikt kommen kann, aber das weiß das DBMS ja nicht.

Mein Trigger so weit:

SQL-Code:

DELIMITER //

DROP TRIGGER IF EXISTS update_T10;

CREATE TRIGGER update_T10 AFTER UPDATE ON tanks FOR EACH ROW
BEGIN
  IF NEW.tank_nr IN (1, 2, 3, 5) THEN
    UPDATE tanks 
    SET inhalt = (
      SELECT SUM(inhalt) 
      FROM tanks 
      WHERE tank_nr IN (1, 2, 3, 5)) 
    WHERE tank_nr = 10;
  END IF;
END; //

DELIMITER ;

T10 soll also die Summe der Inhalte von T1, T2, T3 und T5 bekommen. Ein Update findet also nicht statt, wenn sich der Inhalt von T10 selbst ändert, sodass kein rekursiver Endlosaufruf passieren kann. Kann ich das dem DBMS irgendwie begreiflich machen? Kann man statt "FOR EACH ROW" vielleicht etwas spezifischer werden?

[hoika]

Hallo,
ist MariaDB sowas wie MySQL?

Dann steht hier die Lösung (Stored Procedure nehmen)
https://stackoverflow.com/questions/...e-after-insert

[Medium]

Das ist ein Fork von MySQL bevor es von Oracle übernommen wurde, und wird vom Originalentwickler auch weiter entwickelt. Sehr hübsches DBMSchen.

Darauf war ich auch gestoßen. Leider ist es keine Option für mich, das Update in eine SP zu verpacken, da die Tankfüllstände z.T. von einem Programm geupdated werden, auf das ich keinen Zugriff habe. Und selbst bei denen, die ich selbst update wäre das ein Mega Umbau, da dies mit einer generalisierten Methode passiert, die alle möglichen Werte aus SPSen in Tabellen verteilt - es wäre also die komplette Anlangensteuerung betroffen. Nope.

[jobo]

Die Trigger Idee finde ist kritisch. Die "künstliche" Aggregation macht man auch nicht ohne Not.
Statt dessen einfach einen View anlegen
der entweder
den virtuellen Tank als Berechnung darstellt.
oder
den virtuellen Tank und seine "Eltern" gemeinsam darstellt.

Vorteil:
Minimal Invasiv
Null Impact auf das Bestandssystem.
Keine Gefahr, dass ein weiterverarbeitendes System den virtuellen Tank "für voll nimmt"

Nachteil u.U.:
mögliches Performance Problem

OT
mySQL und Maria würde ich nicht als nett bezeichnen, sondern als tükisch und endlosen Quell von Fehlern und Irrtümern.

[Medium]

Ein View ist eine super Idee! Daran habe ich irgendwie überhaupt nicht gedacht. Danke!

Zitat:

Zitat von jobo (Beitrag 1470848)

Nachteil u.U.:
mögliches Performance Problem

Kaum. Die Tabelle hat popelige ~60 Zeilen und keine komplexen Felder. Und bevor da Zeilen hinzu kommen, muss der Kunde erstmal eine neue Tankfarm bauen :)

Zitat:

Zitat von jobo (Beitrag 1470848)

mySQL und Maria würde ich nicht als nett bezeichnen, sondern als tükisch und endlosen Quell von Fehlern und Irrtümern.

Da würde mich mal interessieren, wieso du das sagst. Wir setzen MySQL/MariaDB seit über 15 Jahren ein, und hatten bislang keine Probleme, die ich mehr oder weniger eindeutig auf die Wahl des DBMS zurückführen könnte. Zugegeben: Wir nutzen fast nur absolute Basisfunktionalität, Trigger schon sehr selten, und ich glaube wir haben ein Mal irgendwo eine SP in ein Live-System gebracht, und auch unsere Abfragen gehen selten über mehr als 4-5 Tabellen (zu bestimmt 90% nur eine). MSSQL hat mir schon erheblich mehr Kopfzerbrechen bereitet, aber das war zu großem Anteil auf einfach dem Fakt geschuldet, dass ich so gut wie keine Erfahrung damit hatte. Insbesondere mit der Administration, die ich bei MariaDB eigentlich recht schlank und wohldokumentiert finde.

[jobo]

Gut, Performance bzw. Datenvolumen ist immer relativ. Wenn man auf die Ressourcen bei Webhostern schaut, reichen vielleicht auch kleinere Datenmengen, um ein System an seine Grenzen zu bringen. Im Industrieumfeld eher nicht so ein Problem, außer es geht Richtung Maschinendatenerfassung, IoT usw.

mySQL hat schon lange Probleme (immer?) mit seinen Standardeinstellungen, die bei bestimmten SQL Befehlen dazu führen, falsche Daten auszugeben (Group by..), tückisch, weil man es nur merkt, wenn man handabgezählte Daten einfüllt und das Ergebnis kennt. Alle anderen Systeme, die ich kenne, quittieren derartige Befehle mit Fehlermeldungen. Ein akuter Showstopper aber total safe. In Delphi vergleichbar mit Kompilierfehlern. MySQL bringt in den genannten Fällen "Laufzeitfehler", aber leider ohne Fehlermeldung oder sonstige Hinweise. (etwa so ähnlich: https://www.youtube.com/watch?v=7FeqF1-Z1g0)
Weiter fehlen viele "Standard" Features im Bereich Constraints, es gibt seltsame Limitierungen (z.B. nicht mehr als 61 joins) und eine recht schwache Liste von "Fähigkeiten". Hier irgendwo war gerade z.B. das Thema Geokoordinaten, kann mySQL seit neuestem (Version 8) auch ein wenig, andere Systeme schon "ewig".
mySQL hat seit Oracle in der Weiterentwicklung gelitten (Dauer), bietet dagegen nette Lizenzfallen und es ist für mich ein Rätsel, warum es so häufig benutzt wird.
Wie weit das analog auf Maria zutrifft, kann ich ehrlich nicht sagen. Aber die Systeme sind ja angeblich weitgehend kompatibel ...

Ich würde immer Firebird oder Postgres vorziehen, was ich fast ausschließlich nutze.

[Medium]

Hmm. Group by kommt bei uns auch nur recht selten vor, und da hatte ich scheinbar bisher auch nicht das "Vergnügen" fehlerhafter Ergebnisse. Heisst nicht, dass es das nicht geben mag, aber für unsere (datenbanktechnisch) einfachen Bedürfnisse scheint das unkritisch zu sein. Auch die Features, die ich nicht vermisse, sind sicherlich darauf zurückzuführen, dass wir keine DBMS "Poweruser" sind. Dem Lizenzgeschiss sind wir bewusst mit dem Umstieg auf MariaDB + UniDAC aus dem Weg gegangen. (Anfangs wars noch MySQL + Zeos (also libmysql.dll). Großer Vorteil war, dass wir mit diesem Weg extrem einfach migrieren konnten; insbesondere unsere alte Bestandssoftware (alles Individualentwicklungen, bei denen keiner solch einen "sehr internen und funktional irrelevanten" aber großen Umbau bezahlt hätte).

In Sachen Performance muss ich aber eine kleine Lanze für MariaDB (InnoDB) brechen. Wir haben ein Energiemonitoringsystem für einen Kunden gebaut, bei dem sekündlich ~600 Messtellen abgefragt werden. Dazu werden dann sekündlich Einträge gemacht, und zusätzlich minütliche und stündliche Zeilen aggregiert um Abfragen über große Zeiträume performant zu halten. (Sodass für eine Wochenübersicht nicht 600000 Sätze pro Messwert abgefragt werden müssen, die eh nicht so fein darstellbar wären.) Hier ist noch massig Luft nach oben für weitere Messstellen.
Es sind mittlerweile über 3TB an Daten angefallen, und ich habe einen Viewer zur Kurvendarstellung gemacht, der den nötigen Zeitraum bei jedem Neuzeichnen abruft. Man kann dort flüssig drin scrollen und zoomen, auch übers LAN, (Manchmal dauert der erste Aufruf etwas, vermutlich wird da erstmal wild rumgecached.) Egal ob Daten von vor 2 Jahren oder die aktuellsten. Man muss es halt ein wenig pfiffig anstellen und dem DBMS anpassen - das wird bei anderen wohl auch nicht viel anders sein. Oder ich sehe auch das zu sehr aus einer "Casual User" Perspektive, und das sind eigentlich Peanuts. Für unsere Belange hat's halt immer mehr als gereicht, und mir ist noch nie das DBMS abgestürzt oder hat seltsame Daten geliefert. Ich kann mich an kein einziges Mal erinnern. Von daher wohl wieder eine Frage von "was willst du damit machen?", welches DBMS angemessen ist.