best practise - redundanz bei SQL inserts vermeiden

Re(2): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 07 May 2024 13:41:05 GMT

INSERT ... ON DUPLICAT

Das ist MySQL's Art, "MERGE" zu sagen. MERGE ist halt ANSI SQL.

Re: best practise - redundanz bei SQL inserts vermeiden

sky — Mon, 06 May 2024 15:33:33 GMT

ich habe das bei mir bei einer lösung mit INSERT ... ON DUPLICATE (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html ) gelöst. Keine Ahnung ob das sinnvoll ist, aber es funktioniert.

Re(4): best practise - redundanz bei SQL inserts vermeiden

pong — Fri, 26 Apr 2024 13:57:36 GMT

Was hindert dich an einem Upsert?

Re(3): best practise - redundanz bei SQL inserts vermeiden

ashley77 — Fri, 26 Apr 2024 13:45:39 GMT

hab mich dazu entschlossen, vor dem insert eine abfrage zu starten, die auf duplikate prüft, den unique constraint aber drinnen zu lassen. verursacht weniger db load als temporäre tabellen (und ist einfacher umzusetzen)

damit reduzieren sich die fälle, wo der constraint ausgelöst wird auf ein minimum.
eliminieren kann ich den constraint nicht, weil die eindeutigkeit zu jedem zeitpunkt zu wichtig ist, ebenso die aktualität der daten. und es fälle gibt, wo die abfrage vor dem insert keine garantie der tatsächlichen eindeutigkeit ist zum zeitpunkt des inserts.
kann also inserts nicht verzögern, zusammenfassen, etc... oder zwischenzeitlich die redundanz ignorieren.

** die einwände, dass ein fehlgeschlagener insert einen unüberschaubaren großen rollback verursacht, treffen in meinem fall nicht zu. insofern war die art und weise schon effizient. (habe laufende "einzel-inserts" - siehe obige begründung)

** den philosophischen vermerk, dass man einen fehler auslöst um ihn hinterher zu vermeiden lass ich aber gelten. (auch wenn's in diesem fall effizient zu sein scheint)

** im endeffekt ist es, wie colo schreibt, kosmetischer natur, aber der kunde möchte die meldungen aus seinem monitoring raus. bekommt er. verstehe das auch, die sind viel zu groß um beim monitoring flexibel sein zu können.

Re(5): best practise - redundanz bei SQL inserts vermeiden

XycRo — Wed, 24 Apr 2024 07:28:02 GMT

kommt ma halt so vor als würde PP versuchen hier bei etwas mitzudiskutieren, wovon er keine ahnung hat.. x)

Re(4): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 23 Apr 2024 22:06:01 GMT

erst ein Select ausführen und wenn der Datensatz nicht vorhanden ist, dann ein
Insert.

oder ein MERGE.

Re(2): best practise - redundanz bei SQL inserts vermeiden

pong — Tue, 23 Apr 2024 20:39:16 GMT

Weiß was ich zu tun hab und wie ich es lösen werde.

Die Applikation so umschreiben, dass gar keine Duplicates entstehen oder diese Daten gar nicht erst erzeugen, weils eh keinen Wert zu haben scheinen?

Re(3): best practise - redundanz bei SQL inserts vermeiden

pong — Tue, 23 Apr 2024 20:37:38 GMT

Welchen Wert haben diese Daten, wenn sowieso "weitergemacht" wird?

Re: best practise - redundanz bei SQL inserts vermeiden

ashley77 — Tue, 23 Apr 2024 19:25:29 GMT

Danke für eure Rückmeldungen!

Einige der Argumentationen und Hinweise find ich sehr hilfreich.
Weiß was ich zu tun hab und wie ich es lösen werde.

Re: best practise - redundanz bei SQL inserts vermeiden

colo — Tue, 23 Apr 2024 12:33:11 GMT

Das Problem ist hauptsaechlich kosmetischer Natur. Wenn man das dem Kunden nicht klarmachen kann, kann man sich entweder auf die Hilfe seines RDBMS verlassen (wenn es denn so ein Feature hat - Postgres hat es z. B. via DO NOTHING in einer ON CONFLICT-Clause), oder aber baut sein eigenes Idempotenz-System. Das kann z. B. eine eigene Tabelle sein, wo man seinen eigenen Unique Value fuer alle N-Tupel seiner Daten (im einfachsten Fall den Hash einer String-Konkatenation der Daten, die man in der "primaeren" Tabelle einfuegen will) mitfuehrt, und diese Hilfstabelle auf Existenz eines so errechneten Wertes checkt, bevor man die "primaere" Tabelle mit dem INSERT belaestigt. Kann natuerlich - ja nach Isolation Level und Transaktionsaufkommen/-verhalten immer noch zur (versuchten) Verleztung des UNIQUE-Constrains in der "primaeren" Tabelle fuehren, aber sicherlich nicht mehr so oft, dass es in den Logs stoert, wenn jemand dort stierln geht.

Re(3): best practise - redundanz bei SQL inserts vermeiden

pyti2000 — Tue, 23 Apr 2024 10:54:09 GMT

Unique constraint ist auch üblich, aber in diesem Fall versuchst du die Daten mit "Tricks" zu prüfen.
Du kannst auch im Code erst ein Select ausführen und wenn der Datensatz nicht vorhanden ist, dann ein Insert.

Re(4): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 23 Apr 2024 10:09:54 GMT

"hatschat" - aber effizient.

Glaube ich nicht - das Error handling erfolgt idR zeilenweise (performancemässig tödlich) und will jedesmal die laufende Transaktion zurückrollen, wenn man das nicht aufwändig abfängt.

Die Idee, statt einer Lösung die Warnings zu unterdrücken, finde ich auch eher russisch...

Re(2): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 23 Apr 2024 10:07:02 GMT

hau danach die Dubletten

Noch besser gar nicht erst inserten.

Re(3): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 23 Apr 2024 10:04:54 GMT

meine frage: ist ein unique constraint unüblich

(Unique) Constraints sind nicht allgemein unüblich, nur in bestimmten Szenarien, zB im Data Warehousing.

Unüblich weil hatschert ist es, einen Regelprozess in einen Fehler (constraint violation) laufen zu lassen und hintennach abzufangen. Ist auch ineffizient, weil die Fehlerbehandlung im Zweifelsfall zeilenweise (RBAR) passiert und wahrscheinlich die ganze laufende Insert-Transaktion zurückgerollt werden muss.

Re(3): best practise - redundanz bei SQL inserts vermeiden

hhetl — Tue, 23 Apr 2024 10:04:54 GMT

meine frage: ist ein unique constraint unüblich

Re(3): best practise - redundanz bei SQL inserts vermeiden

Paulas_Papa — Tue, 23 Apr 2024 06:46:40 GMT

Deine Lösung ist "hatschat" - aber effizient.

Ich würde mit den DBA's reden, was sie an den Warnings stört. Vielleicht können sie diese wegfiltern, damit ihr Monitoring nicht "versaut" wird.

Re(2): best practise - redundanz bei SQL inserts vermeiden

ashley77 — Tue, 23 Apr 2024 05:53:08 GMT

thx - ist natürlich ein weg. hab noch ne menge andere ideen das zu lösen.

der DB load, den ich dadurch erzeuge ist ungleich höher.
warum würdest du trotzdem diesen weg den contraints vorziehen?

Re(2): best practise - redundanz bei SQL inserts vermeiden

ashley77 — Tue, 23 Apr 2024 05:51:32 GMT

thx - hab von euch 2 lösungen vorgeschlagen bekommen.
mir fallen noch 5 andere wege ein das zu lösen.

meine frage: ist ein unique constraint unüblich bzw. warum würde man das so nicht (mehr) lösen?

Re: best practise - redundanz bei SQL inserts vermeiden

Paulas_Papa — Mon, 22 Apr 2024 18:06:02 GMT

Schalt den Constraint aus, mach’s Insert und hau danach die Dubletten raus.

https://madafa.de/blog/duplikate-aus-sql-tabellen-entfernen

Re: best practise - redundanz bei SQL inserts vermeiden

pyti2000 — Mon, 22 Apr 2024 16:07:17 GMT

Ich würde das evtl. datenbankseitig lösen. Du schreibst einfach alle Daten in eine Hilfstabelle, dann hast du alle Möglichkeiten mit select into, distinct, if not exists etc. die richtige Tabelle zu befüllen.

Re: best practise - redundanz bei SQL inserts vermeiden

pyti2000 — Mon, 22 Apr 2024 16:07:17 GMT

Ich würde das evtl. datenbankseitig lösen. Du schreibst einfach alle Daten in eine Hilfstabelle, dann hast du alle Möglichkeiten mit insert into, distinct, if not exists, where etc. die richtige Tabelle zu befüllen.

Re(2): best practise - redundanz bei SQL inserts vermeiden

ashley77 — Mon, 22 Apr 2024 15:02:51 GMT

nein, der user bekommt davon gar nichts mit.
die "fehlermeldungen" (die ja keine sind) sieht der DB admin in seiner konsole.

es werden immer wieder (ähnliche) daten importiert in die DB, aber mit hilfe des unique constraints eben doppelte einträger verhindert. und somit nur neue daten importiert.

die vom INSERT getriggerte exception wird in der app im code abgefangen und dann ganz normal weiter gemacht.

Re: best practise - redundanz bei SQL inserts vermeiden

Paulas_Papa — Mon, 22 Apr 2024 14:51:38 GMT

Wie stelle ich mir den Use Case vor? X Leute nutzen deine App parallel und erfassen Daten.
Und plötzlich kriegt einer von der App den Error, dass beim Insert der Key nicht UNIQUE war?

Wie oft hast du bei Amazon, Whatsapp, XYZ so eine Warnung erhalten?

Als "normaler" Kunde würde ich das als Bug "empfinden". Im Auf/Vertrag wird natürlich nichts dazu erwähnt sein - daher schmecks.

best practise - redundanz bei SQL inserts vermeiden

ashley77 — Mon, 22 Apr 2024 14:40:59 GMT

kurze frage an SQL spezialisten:
=> habe eine App programmiert und SQL DB, in die laufend daten eingetragen werden
=> um redundante daten zu vermeiden, wurde ein unique constraint erstellt. die app fängt beim INSERT die exception ab.

kunde beschwert sich, dass er zu viele unique key constraints meldungen bekommt und will sie eliminiert haben... bugfix oder feature request?

wie ist hier die best practise?
(hab es vor - zugegeben - sehr langer zeit mit unique constraints gelernt.
aber evtl. diese vorgehensweise nicht mehr üblich?)