Division durch 0 vermeiden

Hallo,

ich suche nach einer Variante, die ich in Oracle mit DECODE gelöst hätte.

Was ist an meinem Ansatz, das ursprüngliche Value einzusetzen, wenn der Spaltenwert größer Null ist, falsch?

Select
...
sum(fd.session_duration),
  case 
    when sum(fd.session_duration)= 0 then 1
    else sum(fd.session_duration) > 0 then sum(fd.session_duration)
  end
FROM
...

Viele Grüße,

Christian

Falsch vielleicht nichts - aber ich kenne deine Programmlogik nicht.

Warum ist dort ‘0’ als Wert erlaubt, wenn es zu Problemen kommen kann? Da würde ich einen CHECK bevorzugen, der diesen Wert gar nicht zulässt.

irgendwie alles?

gehts so besser?

Select
...
  SUM (
     case when fd.session_duration = 0 then 1 else fd.session_duration 
     end)
FROM
...

weil du willst doch schauen ob der spaltenwert 0 ist und nicht die summe …

Hallo ads, die Daten werden mit pg_bulkload eingelesen. So ziehen constraints leider nicht. :frowning:

naund … bereite sie doch beim insert auf - dafuer gibt es trigger - alles was 0 ist wird 1

Die Daten werden bei pg_bulkload einfach in die Daten-Dateien geschrieben und die SQL engine wird umgangen. Da ziehen leider auch keine Trigger.

ach so - ich habe mir darunter was anderes vorgestellt

zu solchen dingen wie pg_bulkload will ich mich dann doch nicht weiter aeußern :wink:

Aber Tools wie grep und Co. existieren, damit kann man die Daten vorab aufbereiten.

Ich finde es unschön, fehlerhafte Daten zu speichern und dann hinterher Aufwand zu betreiben, um um diese fehlerhaften Daten herumzuarbeiten. Lieber gleich die Daten richtig aufbereiten und passend in die Datenbank schreiben.

noch mal langsam: pg_bulkload (ich kenne es nicht) ermöglicht es, falsche (ungültige) Daten in die DB zu schleusen?

Andreas

Nun, laut Readme (gerade mal gestöbert) nehmen die an, dass man die Daten in valider Form vorliegen hat (z. B. nach einem Backup).
In so einem Fall kann man sich die Validierung sparen.

Wer natürlich das Werkzeug nutzt, um an der Engine vorbei invalide Daten in die DB zu schreiben, darf sich über Schmerzen und Folgekrankheiten wirklich nicht wundern.

Die Aussage im Readme ist auch sehr eindeutig: wenn man die Datenintegrität nicht sicherstellen kann, soll man das nicht nutzen.

Da bin ich voll und ganz Deiner Meinung! :wink: Ich bin nur leider für den Input nicht verantwortlich und muss die Daten akzeptieren. :frowning: Außerdem ist es ja auch nicht schlecht, wenn man manche Fehler abfangen kann.

Dann bereite die Daten vorab auf. Oder nutz nicht pg_bulkload sondern eine der anderen Möglichkeiten.

Da du offensichtlich invalide Daten an der Datenbank vorbei in die Dateien schreibst, brauchst du dich nicht zu wundern, wenn du danach mit Problemen in der Anwendung zu kämpfen hast.

Das ist doch bloß Rumdoktoren an den Symptomen und du hast auf ewig Performance Einbußen durch all die Workarounds.

Ja, aber dafür rattenschnell! :smiley: Erlaubt ist, was funktioniert. Ich arbeite natürlich daran, saubere Daten zu bekommen aber möglich ist es, auf diesem Wege die Constraints zu umgehen.

Hallo Symbiont, hab Dank für Deine Korrektur!

Mein funktionierendes und für mich sinnvolles Statement lautet nun wie folgt:


SELECT
...
  sum(fd.volume_up) as volume_up,
  sum(fd.session_duration) as session_duration,
  sum(case when session_duration = 0 then 0 else volume_up/session_duration end) as throughput
...

PFUI!!!

aber …

Nix Aber!

Wenn es nicht unbedingt “Rattenschnell” gehen muss - also “Geht ab wie Schmidts Katze” reicht - dann nimm doch z.B. den eingebauten COPY befehl!

Dann schimpfen wir auch nicht mehr mit Dir - versprochen!

Für mich ist es wichtig, die Daten so schnell wie möglich in die DB zu bekommen, da ständig Neue folgen. Danach habe ich Zeit, die Daten aufzubereiten und zu verdichten. Ich gehe auch davon aus, dass die Daten sauber sind und werde das noch einmal besprechen. Nun, hier bei den Testdaten waren eben ein paar schwarze Schafe dabei …

Danke! :smiley:

Nein, es muss leider “rattenschnell” gehen. Der “copy”-Befehl ist leider zu langsam.

So müsst Ihr weiter mit mir schimpfen und ich mich mit den Symptomen aufhalten, tut mir leid! :frowning:

Um die Zweifel am Leben zu erhalten

Warum muss es denn “Rattenschnell” gehen … vielleicht benutzt du ja auch nur COPY falsch :wink:

Die sache ist nämlich die - du schießt dir mit dem bulk selbst ins knie merkst es aber erst wenn dir die kugel durchs linke auge in den ruecken eindringt - naemlich dann wenn du abfragen fahren musst … ich nehme mal an, dass dieses bulk keine indexe erzeugt - usw. wie soll man auf dem Ergebnis" gescheit arbeiten?

Die Daten von fünf Minuten muss ich in 2,5 Minuten importiert haben (Zielvorgabe), damit ich eine Chance habe, falls der Job einmal abbricht/scheitert, den Datenfluss wieder einzuholen. Das habe ich nur mit pg_bulkload geschafft.

halbiere oder viertel die daten doch einfach … setz entsprechend viele clients drauf an die in vier baugleiche tables inserten (partitioinen) … du wirst sehen … ist fast wie zauberei