Filtrowanie danych to moment, w którym baza przestaje być magazynem a staje się narzędziem. W n8n Data Tables różnica między trafieniem w konkretny rekord a zalewem niepotrzebnych wyników zależy od kilku decyzji konfiguracyjnych – wyboru operatora, logiki Any/All, ustawienia limitu i obsługi wielkości liter. W tym artykule pokazujemy, jak poprawnie skonfigurować węzeł Get Rows: od podstawowych operatorów filtrowania przez najczęstszy cichy błąd (case sensitivity) po optymalizację wydajności i ochronę wrażliwych danych.
- Czym jest węzeł Get Rows w n8n Data Tables?
- Operatory filtrowania – Equals, Not equals i kiedy ich używać
- Logika Any vs All – jak łączyć wiele warunków
- Pułapka wielkości liter – skąd się bierze "No item found"?
- Limit=1 i ochrona danych – dwie optymalizacje w jednym kroku
- FAQ – Najczęstsze pytania o Data Table n8n filtrowanie
- Podsumowanie
Czym jest węzeł Get Rows w n8n Data Tables?
Get Rows to węzeł do pobierania rekordów z tabeli n8n Data Tables według zdefiniowanych warunków. Zamiast pobierać całą zawartość tabeli, określasz kryteria filtrowania i odzyskujesz tylko te wiersze, które je spełniają.
W praktyce Get Rows najczęściej pojawia się w dwóch kontekstach. Pierwszy to wyszukiwanie konkretnego rekordu na podstawie wartości z poprzedniego węzła (np. imienia wpisanego przez użytkownika w czacie). Drugi to pobieranie grupy rekordów spełniających określone kryterium (np. wszystkich osób o randze “commander”). Podstawy pracy z Data Tables – w tym tworzenie tabel i dodawanie rekordów przez formularz – opisujemy szczegółowo w artykule o formularzu n8n i Data Tables.
Operatory filtrowania – Equals, Not equals i kiedy ich używać
Każdy warunek w Get Rows składa się z trzech elementów: nazwy kolumny, operatora i wartości. Dwa podstawowe operatory tekstowe:
Equals (Równa się): Zwraca rekord tylko przy idealnym dopasowaniu wartości. Jeśli w tabeli masz wpis “Chris” i filtrujesz po name = Chris, system zwróci dokładnie ten rekord i tylko ten. Jakikolwiek brak dopasowania i wynik jest pusty.
Not equals (Nie równa się): Zwraca wszystkie rekordy, których wartość w danej kolumnie różni się od podanej. Potężne narzędzie do wykluczeń. Jeśli tabela zawiera 10 rekordów, a Ty filtrujesz name ≠ Bart, system zwróci pozostałe 9. Dlatego warto stosować go ostrożnie, szczególnie przy dużych tabelach – łatwo o niezamierzony “wyciek” wielu rekordów do workflow.
Logika Any vs All – jak łączyć wiele warunków
Gdy definiujesz więcej niż jeden warunek filtrowania, n8n pyta jak je połączyć. Opcja na poziomie sekcji Filter decyduje o tym, czy rekord musi spełniać każdy warunek jednocześnie, czy wystarczy spełnienie jednego z nich.
Must match any condition (logika “lub”): Rekord zostaje zwrócony, jeśli spełnia co najmniej jeden z zdefiniowanych warunków. Odpowiednik SQL WHERE kolumna_A = 'X' OR kolumna_B = 'Y'.
Must match all conditions (logika “i”): Rekord zostaje zwrócony tylko wtedy, gdy spełnia wszystkie warunki jednocześnie. Odpowiednik SQL WHERE kolumna_A = 'X' AND kolumna_B = 'Y'.
Przy jednym warunku wybór między Any i All nie ma znaczenia – wynik jest identyczny. Różnica ujawnia się dopiero przy dwóch lub więcej warunkach. W pracy z chatbotem najczęściej potrzebujesz precyzyjnego dopasowania po konkretnym identyfikatorze, dlatego domyślnym wyborem jest “all conditions” – zwłaszcza gdy jeden warunek to ID lub unikalny klucz.
Pułapka wielkości liter – skąd się bierze “No item found”?
Najczęstszy “cichy błąd” przy filtrowaniu danych w n8n to case sensitivity, czyli rozróżnianie wielkości liter. Filtry w Data Tables domyślnie traktują “MAT”, “Mat” i “mat” jako trzy różne wartości.
Scenariusz: w tabeli przechowujesz imię “mat”, ale użytkownik w czacie wpisuje “MAT”. Zapytanie Get Rows z warunkiem name = MAT nie znajdzie rekordu i zwróci pustą odpowiedź. Dla algorytmu to dwa różne ciągi znaków.
Rozwiązanie to standaryzacja danych wejściowych przed wysłaniem zapytania do tabeli. Przed węzłem Get Rows dodajesz węzeł Code lub Edit Fields, który normalizuje wartość do jednego formatu (np. zawsze małe litery przez $json.chatInput.toLowerCase()). Ponieważ wartość z czatu przechodzi przez standaryzację zanim trafi do filtra, dopasowanie działa niezależnie od tego, jak użytkownik napisał dane słowo.
Dodatkowa wskazówka przy debugowaniu: jeśli po poprawieniu logiki błąd nadal się pojawia, odśwież sesję czatu lub użyj nowego linku testowego. Czat czasem przechowuje dane z poprzednich sesji w pamięci podręcznej, co może maskować rzeczywisty wynik.
Limit=1 i ochrona danych – dwie optymalizacje w jednym kroku
Gdy Get Rows szuka konkretnego rekordu (np. jednej osoby po imieniu), nie ma powodu, żeby pobierał dziesiątki wyników. Parametr Limit pozwala ograniczyć liczbę zwracanych wierszy. Ustawienie Limit = 1 oznacza, że workflow pobiera tylko pierwszy pasujący rekord i kończy przeszukiwanie tabeli.
Poza wydajnością jest drugi powód, żeby ograniczać dane: ochrona wrażliwych informacji. Rekordy w Data Tables często zawierają więcej niż to, co chcesz pokazać użytkownikowi. Obok imienia i rangi mogą pojawić się techniczne ID, daty modyfikacji, wewnętrzne tagi. Przesyłanie tych metadanych przez workflow to nie tylko szum informacyjny, ale też potencjalne ryzyko nieautoryzowanego dostępu do danych krytycznych.
Po Get Rows dodajesz węzeł Edit Fields, który wyciąga tylko te kolumny, które faktycznie są potrzebne do odpowiedzi. Reszta jest odfiltrowana i nie trafia ani do modelu AI, ani do interfejsu użytkownika. Szczegółowe omówienie możliwości węzła Edit Fields w tym kontekście znajdziesz w artykule o transformacji danych w n8n.
Kurs n8n 2.0 · Kodożercy
Ile godzin tygodniowo tracisz na powtarzalne zadania?
n8n pozwala zautomatyzować to co robisz ręcznie – przesyłanie danych, powiadomienia, raporty. Kurs n8n 2.0 na Kodożercach pokaże Ci jak, krok po kroku, bez pisania kodu.
Sprawdź kurs n8n 2.0 →
FAQ – Najczęstsze pytania o Data Table n8n filtrowanie
Ile warunków filtrowania można dodać w Get Rows?
N8n nie narzuca twardego limitu liczby warunków w węźle Get Rows. W praktyce możesz łączyć dowolną liczbę warunków z logiką Any lub All. Jednak wraz ze wzrostem liczby warunków rośnie złożoność logiki i ryzyko błędów konfiguracyjnych. Gdy zapytanie staje się bardzo złożone, warto rozważyć wstępne przefiltrowanie danych w węźle Code przed Get Rows.
Czy Data Table w n8n to baza danych na produkcję?
Data Tables w n8n to wbudowane tabele danych dostępne bez zewnętrznych integracji – idealne do nauki, prototypowania i prostych workflow. Jednak przy dużych wolumenach danych (tysiące rekordów) lub wymaganiach produkcyjnych (backupy, replikacja, transakcje) lepszym wyborem jest dedykowana baza danych (PostgreSQL, MySQL) podłączona przez integrację n8n. W kursie n8n 2.0 pokazujemy Data Tables jako fundament – żeby zrozumieć mechanizmy filtrowania zanim przejdziesz do zewnętrznych baz.
Co zrobić, gdy Get Rows zwraca 0 wyników mimo że rekord istnieje?
Najczęstsze przyczyny to kolejno: case sensitivity (sprawdź wielkość liter w wartości wyszukiwanej i w bazie), białe znaki na początku lub końcu wartości (np. spacja po wklejeniu danych), błędna nazwa kolumny w warunku filtrowania lub świeży cache sesji czatu (odśwież lub użyj nowego linku testowego). Zakładka Executions w n8n pozwala zobaczyć dokładnie jakie dane trafiły do węzła Get Rows – to pierwsze miejsce do sprawdzenia przy debugowaniu.
Jak działa Data Table Get Rows w połączeniu z chatbotem?
W typowym workflow chatbota użytkownik wpisuje wartość (np. imię) w interfejsie czatu, trigger On Chat Message przekazuje ją do workflow, a węzeł Edit Fields lub Code standaryzuje wielkość liter. Następnie Get Rows pobiera pasujący rekord, Edit Fields filtruje zwrócone pola do niezbędnego minimum i wynik trafia do modelu AI lub bezpośrednio do odpowiedzi czatu. Taki schemat opisujemy w praktycznym projekcie end-to-end w artykule o n8n, OpenAI i Data Tables.
Podsumowanie
Data Table n8n filtrowanie przez węzeł Get Rows opiera się na kilku zasadach, które warto zapamiętać: operatory Equals i Not equals decydują o typie dopasowania, logika Any/All określa jak łączyć wiele warunków, case sensitivity to najczęstszy cichy błąd, a Limit=1 chroni zarówno wydajność, jak i wrażliwe dane. Węzeł Edit Fields po Get Rows to ostatnia linia obrony przed wyciekiem metadanych do interfejsu użytkownika. Opanowanie tych mechanizmów to fundament każdego chatbota zasilonego danymi z własnej bazy.
