Wyszukiwanie zaawansowane w oprogramowaniu dla firm - jak rozwiązują to różne systemy

Prawie każdy system biznesowy prędzej czy później dochodzi do tego samego problemu: prosta wyszukiwarka po nazwie nie wystarcza. Użytkownik chce znaleźć “klientów bez kontaktu od 30 dni”, “zgłoszenia o priorytecie wyższym niż 2 w statusie otwartym” albo “osoby z regionu X, które wydały ponad 10 tys.”. To wymaga budowania warunków: pole, operator, wartość - i łączenia ich w grupy. Poniżej jak podchodzą do tego popularne narzędzia.

Wspólny wzorzec

Niezależnie od nazwy (filtry, widoki, segmenty, listy) mechanizm jest wszędzie podobny. Warunek to trójka: pole, operator i wartość. Operatory zależą od typu pola - tekst ma “zawiera”, liczba ma “większe/mniejsze”, data ma “przed/po”. Warunki łączy się spójnikiem: wszystkie muszą być spełnione (AND) albo wystarczy jeden (OR). Bardziej rozbudowane systemy pozwalają zagnieżdżać grupy, czyli budować logikę typu “A oraz (B lub C)”.

Airtable

Filtrowanie wbudowane w widok. Po wybraniu pola pojawia się lista operatorów dopasowana do jego typu. Można tworzyć grupy warunków zagnieżdżone w innych grupach i łączyć je spójnikami. Filtr działa na poziomie widoku - ten sam arkusz można oglądać przez różne widoki z różnymi filtrami.

Notion

Zaawansowany filtr pozwala wybrać właściwości do filtrowania i ustawić logikę AND/OR. Filtry są częścią widoku, podobnie jak w Airtable - zmiana filtra nie rusza danych, tylko sposób ich prezentacji.

HubSpot

Rozbudowany silnik list i segmentów. Filtry są drzewem: gałęzie łączone operatorem AND lub OR, w gałęziach pojedyncze warunki, a gałęzie mogą mieć pod-gałęzie. Segmenty (listy) są zapisywane i mogą być statyczne albo dynamiczne (odświeżają się automatycznie, gdy rekord zaczyna spełniać warunki). HubSpot pozwala też filtrować po przynależności do innego segmentu.

Salesforce

List views i reporty z filtrami po polach oraz - co istotne dla wydajności - polami wyliczanymi (rollup), które agregują dane z rekordów powiązanych (np. suma wartości szans sprzedaży) i są zapisywane wprost na rekordzie nadrzędnym. Dzięki temu filtr “klienci z szansami powyżej X” trafia w gotową kolumnę, a nie liczy w locie.

Jira

Własny język zapytań (JQL) - tekstowy, gdzie wpisuje się warunki, operatory i funkcje (w tym daty względne, np. “zmienione w ciągu ostatnich 7 dni”). Obok jest tryb wizualny dla mniej technicznych użytkowników. Zapytania można zapisywać jako filtry.

Sugester 1 (S1)

Wcześniejsza generacja naszego systemu opierała wyszukiwanie zaawansowane na gemie Ransack. Dawało to bogaty zestaw operatorów (zawiera, równe, większe/mniejsze, jest puste), grupy warunków AND/OR, warunki po tabelach powiązanych (np. transakcje, aktywności) budowane automatycznymi JOIN-ami, a także zapisywane filtry. Miało też ciekawy mechanizm “warunków dynamicznych” - w polu wartości można było wpisać wyrażenie w podwójnych klamrach, np. odpowiednik “30 dni temu”, zamieniane na konkretną datę w momencie wyszukiwania (przydatne np. do filtrów urodzinowych czy przypomnień). Wadą podejścia z automatycznym JOIN-em jest wydajność przy dużych bazach - łączenie tabel i odsiewanie duplikatów potrafi być kosztowne.

Intum

W Intum zbudowaliśmy własny silnik warunków zamiast opierać się na zewnętrznym gemie. Kluczowa decyzja: jeden język warunków (format JSON: pole, operator, wartość, grupy) obsługiwany przez dwa “silniki” - jeden tłumaczy go na zapytanie SQL (filtry list), drugi ocenia ten sam warunek w pamięci (automatyzacje i reguły). Dzięki temu filtr zbudowany na liście klientów mówi tym samym językiem co warunek reguły automatyzacji - można je swobodnie przenosić.

Co mamy: operatory dobierane po typie pola (zawiera, zaczyna/kończy się, równe, różne, większe/mniejsze, jest wypełnione), grupy AND/OR z dowolnym zagnieżdżaniem, warunki dynamiczne z datami względnymi (np. odpowiednik “30 dni temu”, “dziś”, “teraz”), zapisywane segmenty (prywatne albo współdzielone na koncie), oraz - dla mocy bez komplikowania interfejsu - opcję wpisania własnego warunku w JSON, którą wykorzystuje też asystent AI. Bezpieczeństwo pilnuje whitelista pól: filtrować można tylko po polach dozwolonych dla danego modelu, więc nie ma dostępu do przypadkowych kolumn ani ryzyka wstrzyknięcia SQL. Dla szybkiej segmentacji “po powiązaniach” (np. data ostatniej aktywności, liczba kontaktów, suma wpłat) używamy pól wyliczanych zapisanych wprost na rekordzie klienta - to samo podejście co Salesforce, wydajne bo indeksowane. Panel filtra ładuje się dopiero po kliknięciu, żeby nie obciążać każdej listy.

Różnica względem S1: zamiast automatycznych JOIN-ów Ransacka idziemy w stronę pól wyliczanych (szybkie, indeksowane) plus - docelowo - zapytań typu EXISTS dla warunków po tabelach zależnych, które nie mnożą wierszy i lepiej się skalują.

Porównanie w tabeli

Legenda: ✅ pełne wsparcie, 🟡 częściowe / z ograniczeniami, ➖ brak / nie dotyczy.

Gdzie Intum wychodzi na prowadzenie: jeden język warunków wspólny dla filtrów list i reguł automatyzacji (filtr da się przekuć w regułę), tryb własnego JSON obsługiwany też przez asystenta AI (opisujesz po ludzku, on układa warunek), oraz podejście wydajnościowe - warunki po powiązaniach jako EXISTS i pola wyliczane zapisane na rekordzie, zamiast kosztownych automatycznych JOIN-ów z odsiewaniem duplikatów (słaba strona rozwiązania z Sugestera 1). Reszta rynku ma pojedyncze z tych rzeczy; w Intum spina je jeden mechanizm.