PQ - Gruppenzuordung über Index

[Jack_d]

Moin Ralf ,

danke nochmal.

Hilf mir kurz .. Ist das nicht das gleiche nur, dass du es in ne Funktion auslagerst?
Wieso ist das dann schneller?

Deine Vermutung zu PowerPivot kann ich bestätigen. Ich nutz es nur äusserst selten, da ich idR mir das in PQ bereits zurechtbastel
komm ich mutmaßlich besser mit zurecht, auch wenn die Vorteile bei 1:n Daten auf der Hand liegen

Grüße Jack

Edith sagt:
Ich musste Excel killen .. der Code hat es in die Knie gewzungen

[Ralf A]

...hmmm... nun ja... hatte mir die Spalte "Nächster Termin" gespart. Und auswerten muss man es so oder so. Zeile für Zeile. Selbst wenn man mit List.Generate eine Liste erstellen ließe, müssen immer alle relevanten Werte ausgewertet werden.
Wüßte jetzt nicht, wie man das sonst lösen sollte.
Die Funktion hat übrigens folgenden Aspekt nicht berücksichtigt: Wenn (z. Bsp. durch Eingabefehler) der nächste Termin vor dem Ende des letzten liegt. Das kann dann so abgefangen werden:

PHP-Code:

(Ende as number, nextStart as number, Startdatum as date, NextDat as date, enderaum as text, startraum as text) =>

let
    Ergebnis = 
    if Startdatum = NextDat then
        if startraum = enderaum then
           if nextStart < Ende then 0 else nextStart - Ende 
        else ""
    else ""
in
    Ergebnis 


Überall da, wo dann 00:00:00 steht, stimmt irgendwas nicht....

Ich musste Excel killen .. der Code hat es in die Knie gewzungen

Vielleicht doch kleinere Brötchen backen und den Zeitraum eingrenzen?

[Jack_d]

Nunja,

mit der Änderung von Detlef (Table.Buffer) hat es meine Version hinbekommen. ...
auch der Code von Luschi läuft- auch wenn ich ihn leider nicht verstehe.
auch dein Code läuft  - wenn auch mit geringeren Mengen

Die Funktion hat übrigens einen Aspekt nicht berücksichtigt: Wenn (z. Bsp. durch Eingabefehler) der nächste Termin vor dem Ende des letzten liegt. Das sollte dann so behandelt werden:

Stimmt -- hab das so gelöst, dass ich negative Differenzen (2 Datensätze) eliminiere

Wüßte jetzt nicht, wie man das sonst lösen sollte.

Indem man den Datensätzen verschiedene Indizies  gibt und so über einen Join den nachfolgenden Datensatz anhängt (index +1)
Dann kannst Spaltendifferenzen berechnen.
Das ist zumindest für mein begrenztes Verständnis der effektivste Weg.

Den ganzen Datenbankern wie Ebs und CO, werden da sicher auch noch andere Lösungen schiessen, 
weil das zumindest mutmaßlich in der DB Welt häufiger vorkommt

Grüße Jack

[Ralf A]

Stimmt -- hab das so gelöst, dass ich negative Differenzen (2 Datensätze) eliminiere

...ob das so gut ist? Das sind doch gebuchte Termine, oder nicht? Die sollten korrigiert werden. Dazu müssen sie erkannt werden. Aber... weg ist weg...  Oder geht's nicht um die Planung sondern wirklich nur um die Auswertung.... na dann ist's egal, wenn 2 DS fehlen... 

[Jack_d]

Eben bei n>12k bewegen wir uns in nem Fehlerniveau von 0,01-0,02 Prozent

Das gilt es zu vernachlässigen

[ws-53]

Ich habe nun auch eine Lösung erstellt, die auch wie die Lösung von Luschi nur ca. 2 Sekunden für knapp 22.000 Datensätze benötigt. Der hauptsächliche Unterschied besteht darin, dass ich die Anzahl Minuten bis zum Beginn der nächsten Belegung ermittle, währen Lusiche das Ende zuvor ermittelt.

Die Testdaten sowie die Auswertung werden beim öffnen der Mappe generiert.

[Jack_d]

Danke WS53

Kann es mir aber erst am Montag anschauen 

Grüsse

[Jack_d]

Hallo WS 53

Danke für deine Lösung .. sie funktioniert wunderbar.
Ist im KErn gleich meines ersten Lösungsansatzes.
Da hat es nur die Zuordnung verschossen .. warum auch immer ..
DIes funktioniert in deiner Lösung allerdings klaglos =)

Grüße Jack

[ws-53]

Hier die Antwort von Ken Puls zu Problemen dieser Art.

The Merge window shows correct results, but the Expand shows a wrong result.

[Jack_d]

Hier die Antwort von Ken Puls zu Problemen dieser Art.

The Merge window shows correct results, but the Expand shows a wrong result.

"I agree that it is less than ideal, but it underscores the importance of always checking the output. "

Is halt insofern ärgerlich (wenn man seinem Vorredner folgt) das es manchmal erst bei einer späteren Bearbeitung auftritt.
- also man teste in nem Muster - funzt - übersetzt es zum eigentlichen
Problem und sieht den Fehler nicht (weil er zb erst beim xten Datensatz auftritt

unbefriedigend