Poszukuje proste rozwiązanie do tworzenia zapytań SQL

Witam.
Potrzebuje pomocy w kwestii generowania zapytań. Mam napisaną aplikację do wysyłania powiadomień do klientów z systemu Comarch Optima. Mój program filtruje odpowiednie dane za pomocą zapytań SQL do tabeli odpowiadającej za stworzone dokumenty w Optimie.
Potrzebuje teraz stworzyć do tego interfejs ale na tyle "idiotoodporny" żeby (powiedzmy) prawie każdy mógł stworzyć sobie takie "zapytanie".
Myślałem nad czymś podobnym do filtrów na poczcie o2 (załącznik)
Wybieramy kolumnę -> opcje -> wartość

Do dyspozycji mam DevExpress.

Jeżeli to aplikacja Winformsowa to masz w Devexpressie kontrolkę do diagramów.

Graficzne "łączenia" odpadają. Ma być proste, a uniwersalne. Nie mogę dać tylko kilku standardowych opcji typu data wystawienia dokumentu, typ dokumentu (faktura, WZ, korekta). Musi to być bardziej obszerne np.: zagraniczny kontrahent, kwota na dokumencie większa niż. Im więcej użytkowników, tym więcej możliwości, więc muszę być przygotowany na najgorsze :D
Boje się, że będę musiał przysiąść do tego i zwyczajnie każdą kolumnę w tabeli nazwać i pozwolić na dowolną opcję na niej, typu: mniejsze, większe, zawiera, zaczyna od, równe, podziel, odejmij itp itd.
Wiecie o co chodzi :D

wiemy. Najpierw odpowiedz na jedno bardzo ważne pytanie - użytkownicy mogą pytać tylko jedną tabelę (lub widok, który im zrobisz) czy kilka? Bo jak kilka to poza SQL albo graficzna budowa zapytań - przy kilku tabelach coś takiego jak dałeś w załączniku jest niewykonalne (a przynajmniej czas na napisanie tego będzie większy niż zysk)

A może użyć filtrów z gridów. Tylko musialbys ppdpiac pod gridy jakies dane.

@AdamWox: nie odpowiadaj w komentarzach na główny temat!

Dla przykładu pokaże kilka zapytań napisanych przeze mnie ręcznie:
Faktura polska

select tn.TrN_TrNID, tn.TrN_NumerPelny, tn.TrN_Bufor from CDN.TraNag tn
left join CDN.Kontrahenci k on tn.TrN_PodID = k.Knt_KntId
where (k.Knt_KrajISO like 'PL' or k.Knt_KrajISO like '') and tn.TrN_TypDokumentu = 302 and tn.TrN_Bufor = 1 and tn.TrN_Korekta = 0 and TrN_TrNID > 203662

Faktura zagraniczna różni się, wiadomo, tylko tym:

where (k.Knt_KrajISO not like 'PL' and k.Knt_KrajISO not like '')

Korekta faktury

tn.TrN_Korekta = 1 --korekta ilości
tn.TrN_Korekta = 2 --korekta wartości

WZ polskie

where (k.Knt_KrajISO like 'PL' or k.Knt_KrajISO like '') and tn.TrN_TypDokumentu = 306

Dodatkowo mogą dojść do tego płatności. Powiadamia danego klienta mailem o niezapłaconym dokumencie:

select tn.TrN_TrNID, tn.TrN_NumerPelny, tn.TrN_Bufor from CDN.TraNag tn
left join CDN.BnkZdarzenia bz on tn.TrN_TrNID = bz.BZd_DokumentID
where tn.TrN_TypDokumentu = 302 and tn.TrN_Korekta = 0 and tn.TrN_Bufor = 0
and bz.BZd_DokumentTyp = 1
and datediff(d, GETDATE(), bz.BZd_Termin) = 1 and bz.BZd_Rozliczono = 1 and bz.BZd_Rozliczono2 = 1

#doklejam tutaj to co wpisałem wcześniej nie tam gdzie trzeba
Teoretycznie mam dwa wyjścia: 1. Opisać każdą kolumnę tak żeby użytkownik wiedział czego się tyczy, 2. Zrobić legendę gdzieś pod guzikiem za jakie dane konkretna kolumna odpowiada. Co za tym idzie? Muszę sprawdzać typ kolumny, aby dobrać odpowiednią opcję np.: string - equals, contains, starting with, datetime - equals, more than, less than itp itd, dalszy ciąg już znacie. Mamy sporo klientów, którzy korzystają z Optimy. Powiedzmy, że połowa z nich z tego skorzysta. Jest to wartę czasu?

1. to LIKE czy NOT LIKE to jakaś masakra. Nie używaj LIKE jeśli nie jest to niezbędnie konieczne.
2. Wg mnie jakbyś zamiast się zastanawiać po prostu wziął się za to to już byś miał to zrobione. Wcale nie trzeba do tego "nazywać" ładnie kolumn ani dawać userom dostęp do SQLa. Proste okienko z możliwymi warunkami

• dla dat do wybrania data od - do z możliwością niewypełnienia którejś,
• zamiast warunków typu k.Knt_KrajISO NOT LIKE 'PL' AND k.Knt_KrajISO NOT LIKE '' to prostą listę wyboru polskie/zagraniczne a warunki sam sobie wstawisz na podstawie wyboru
• czy zapłacone
• czy klient powiadomiony
  itd., itp. A jak userom będzie mało to dołożysz kolejne pola, które będą mogli uzupełnić. Także dodanie czegoś na kształt pole wybór_mniejsze/większe/równe edit_wartość to parę linijek kodu

uniwersalne rozwiązanie już ktoś wymyślił - nazywa się SQL i możesz w nim zrobić praktycznie wszystko. Możesz nazwy tabel i kolumn opakować w coś ładnego i mówiącego cokolwiek przeciętnemu Kowalskiemu. Możesz zamiast or pisać lub a zamiast and i. Możesz zrobić, że zamiast pisania SQLa będzie go można układać graficznie. Ale to nadal jest SQL, nadal trzeba znać powiązania między tabelami, nadal trzeba wiedzieć czemu np. TrN_TrNID > 203662 a nie 123456. W końcu możesz to wszystko zrobić, siedzieć nad tym tydzień, miesiąc, rok. A na koniec przyjdzie user i powie, że on chce żeby mógł sobie wybrać czy faktura PL czy zagraniczna i na jaką datę bo to co ma to skomplikowane i myśleć trzeba.

Ja wiem, że Ty jako programista chciałbyś dać userom jak największe możliwości - też tak kiedyś miałem :). Teraz robię tak, że tylko to co jest zebrane w nowych wymaganiach plus ew. jeśli jestem pewny na 100% że coś będzie jako kolejny request a prościej mi to zrobić od razu. I wszyscy są szczęśliwi :).

BTW mam tylko jednego klienta (w sensie jednego człowieka z zakładów, które obsługuje firma, w której pracuję), który by się czymś takim zapewne ucieszył. Ale jest to człowiek, który pilnuje swojego biznesu i wie dokładnie czego mu trzeba. On jako jedyny ma w programie dostęp do pisania zapytań (chociaż często jako request przychodzi prośba o gotowego SQLa a on sobie potem warunki tylko zmienia) a wyniki sobie eksportuje do excela i tam je dalej mieli.

AdamWox napisał(a):

#doklejam tutaj to co wpisałem wcześniej nie tam gdzie trzeba
Teoretycznie mam dwa wyjścia: 1. Opisać każdą kolumnę tak żeby użytkownik wiedział czego się tyczy, 2. Zrobić legendę gdzieś pod guzikiem za jakie dane konkretna kolumna odpowiada. Co za tym idzie? Muszę sprawdzać typ kolumny, aby dobrać odpowiednią opcję np.: string - equals, contains, starting with, datetime - equals, more than, less than itp itd, dalszy ciąg już znacie. Mamy sporo klientów, którzy korzystają z Optimy. Powiedzmy, że połowa z nich z tego skorzysta. Jest to wartę czasu?

Jak ze 20 klientów zapłaci za to po 1500 to może się opłacić. Tylko trzeba by te tabele zamienić na obiekty z typowaniem, żeby odpowiednie operatory i edytory wstawić dla odpowiednich typów. Czyli trzeba przygotować model obiektowy dla tych danych i potem to już łatwizna.