[JaTobieTyMi]

Mirki muszę przygotować widok, który będzie wystawiony na front i będzie obsługiwał filtrowanie po trait. Czyli jeżeli finalny użytkownik na froncie zaznaczy trait emeryt, wyświetli mu sie user1, jezeli zaznaczy emeryt i kawaler to tez bedzie user1, ale jezeli emeryt, kawaler i wdowiec to nic nie dostanie. Jak to najlepiej obsłużyć? Jakąś tablicą?

#sql #bazydanych #programowanie #postgresql #powerbi

[Drmscape2]

@JaTobieTyMi: RLS
https://www.postgresql.org/docs/current/ddl-rowsecurity.html

[janek_]

jedną z opcji jest użycie STRING_AGG() zeby mieć wszystkie traity danego usera w jednym wierszu, a potem dla każdego zaznaczonego traita dodatkowy warunek w where and połączonetraity like '%wybranytrait%'

[file_get_contents]

@JaTobieTyMi: Twój problem sprowadza się do walidacji. Możesz to zrobić a'la ValueObject, czy inne DTO. W konstruktorze napisz logikę, która nie dopuści do nieprawidłowego stanu. Jeśli obiekt będzie prawidłowy, może zwracać tablicę poprawnych wartości przekazanych przez użytkownika. Tych z kolei możesz użyć w zapytaniach SQL.

@Drmscape2: dafaq? ( ͡° ͜ʖ ͡°)

[aloucie]

@JaTobieTyMi: A zwykłe:

users: USERID ...
traits: TRAITID, TRAITNAME
usertraits: UTID, UTTRAITID, UTUSER_ID

select * from users
join usertraits on userid = utuserid
where uttraitid in ( select traitid from traits where traitname in ('emeryt' , 'wdowiec'));

Zwykła tabelka krzyżowa. Jeśli zrobisz dobre API to nawet nie będziesz musiał robić tego nested query, tylko uttraitid in (1, 2)

Opcja @janek_ chyba też spoko, ale bez żadnego like '%xyz%', bo do like

[janek_]

@aloucie: to nie działa. załóżmy że mamy dwóch ludów Eugeniusza emeryta i Wiesława wdowca, twoje zapytanie zwróci ich obu, a powinno żadnego z nich

[aloucie]

@JaTobieTyMi: Co do tabelki - faktycznie, masz rację :) Twoje jest spoko, alr trzeba jednak sortować traity tj. polaczonetraity like '%b,c%' albo dawać kolejnego and'a - polaczonetraity like '%b%' and polaczonetraity like '%c%' (na wypadek 'c,b' - nieposortowanych). Plus te nieszczęsne trigramy z tego co kojarzę. Zwykły btree nie ogarnie takiego wildcarda (chyba że się mylę?)

[aloucie]

@janek_: ^^^

[aloucie]

@JaTobieTyMi: Ewentualnie intarray zamiast tsvector, i do tego znów gin/gist. Tylko takie listy nie obsługują FK, więc spójność zależy od aplikacji :)

[janek_]

@aloucie: sortowanie czy nie nie ma znaczenia - w sensie: nic nie pomoże;
ktoś może mieć cztery cechy, a filtrowanie ma dotyczyć tylko dwóch z nich, i wtedy nie zrobisz tego jednym warunkiem

[aloucie]

@janek_: Zrobisz na ts_vector lub intarray