none
filter vs where und select, Verständnisfrage RRS feed

  • Frage

  • hallo zusammen,

    wieder mal eine/zwei/drei Verständnisfrage(n).

    irgendwie verwirrt das am Anfang noch etwas wann man was wie einsetzen soll.

    (verzeiht falls ich ein falsches und unglückliches Beispiel erwische)

    zb. kann man mit pipe und select -propertiy * alle Felder/Properties anzeigen lassen und mit where Filtern

    get-process | select -property * -First 1

    Get-Eventlog -Logname System -EntryType Error -Newest 20 

    erzeugt ähnliches. Wäre es da nicht einfacher man gewöhnt sich generell den pipe | Select, und where an und man muss nicht bei jedem Cmdlet stundenlang die Hilfe studieren welche Parameter möglich sind?

    rasche Vorgehensweise wäre doch

    1.get-Eventlog => alle Properties/Felder anzeigen

    2.  dann zb. | where EntryType -eq 'Error' => ok die obige Schreibweise ist kürzer aber man muss sich erst die Hilfe zu Gemüte führen.

    get-childitem -filter

    ginge vermutlich auch mit get-childitem | where ...

    pipe -First 1 oder -Newest vom Cmdlet

    um bei dem zweiten Beispiel get-eventlog zu bleiben. Ich glaube mir sind sicher schon einige Exchange cmdlet untergekommen die ebenfalls direkt beim cmdlet ein property * erlauben. Aber vielleicht täusche ich nicht jetzt auch.


    Chris


    • Bearbeitet -- Chris -- Dienstag, 20. Dezember 2016 19:02
    Dienstag, 20. Dezember 2016 18:59

Antworten

  • Chris, wenn es nur um wenige/vereinzelte Abfragen geht und Performance kein Thema ist, kann man das so machen. Es ist aber meistens performanter wenn man die Daten so weit 'links' wie möglich filtert und nur die Daten in die Pipeline weiterreicht, die man auch benötigt. Gerade bei Abfragen im AD kann man zum Teil deutlich Geschwindigkeitsvorteile erzielen.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    • Als Antwort markiert -- Chris -- Dienstag, 20. Dezember 2016 19:23
    Dienstag, 20. Dezember 2016 19:17

Alle Antworten

  • Chris, wenn es nur um wenige/vereinzelte Abfragen geht und Performance kein Thema ist, kann man das so machen. Es ist aber meistens performanter wenn man die Daten so weit 'links' wie möglich filtert und nur die Daten in die Pipeline weiterreicht, die man auch benötigt. Gerade bei Abfragen im AD kann man zum Teil deutlich Geschwindigkeitsvorteile erzielen.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    • Als Antwort markiert -- Chris -- Dienstag, 20. Dezember 2016 19:23
    Dienstag, 20. Dezember 2016 19:17
  • Danke klingt logisch und verständlich

    ;-) dachte schon bei Powershell 1.0 gab es noch keine Pipe Möglichkeit und der jeweilige Cmdlet Entwickler musste die Filter selbst ausprogrammieren (scherz)


    Chris

    Dienstag, 20. Dezember 2016 19:23
  • lol ... aber die PS wird ziemlich agil weiterentwickelt und MS hört inzwischen auch auf seine Anwender. Also was heute noch fehlt und man sich aufwändig zusammenbauen muss, kann in der nächsten Version schon 'out of the box' dabei sein.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Dienstag, 20. Dezember 2016 19:31
  • ja ist mir auch schon aufgefallen. Ist gar nicht lange her da gab es fürs AD nur Quest oder für DNS noch nichts einfaches bzw eigene cmdlet.

    Chris

    Dienstag, 20. Dezember 2016 19:38
  • > Gerade bei Abfragen im AD kann man zum Teil deutlich Geschwindigkeitsvorteile erzielen.
     
    Dem ist eigentlich nichts hinzuzufügen :-))
     
    Get-ADUser | Where liest ALLE Benutzer und wirft hinterher die nicht benötigten fort.
    Bei Get-ADUser -Filter oder Get-ADUser -LDAPFilter filtert dagegen der ausführende Domain Controller selbst schon und liefert nur die gefragten Objekte zurück.
    Das gleiche gilt auch für Get-ChildItem und viele weitere Get-*. Wann immer man nur bestimmte Ergebnisse eines CMDlets braucht und es irgendwie auf Geschwindigkeit ankommt, sollte man prüfen, ob das CMDlet selbst schon filtern kann.
     
    Mittwoch, 21. Dezember 2016 09:49