Witam, mam następujący problem. Przykładowa tabela:



Teraz interesuje mnie ilu unikatowych klientów składało swoje zamówienia.
Niestety przy użyciu



otrzymuję wynik


Zapytanie zlicza mi elementy każdej grupy. Jak zmodyfikować zapytanie, aby wynikiem była łączna liczba unikatowych elementów wszystkich grup czyli '3'?

Ja bym rozbil obecna tabele na 2.
Klienci(id_klienta, imie, nazwisko) + Zamowienia(id_zamowienia, id_klienta, wartosc)
Wtedy nie ma z tym problemow, a i baza jest bardziej optymalna.

Powyższa tabela to tylko przykład, ta rzeczywista jest dużo bardzie skomplikowana i jej dzielenie będzie dość problematyczne.

Póki co kombinuje z count(distinct) i sumowaniem wyników z niego

Cała ta tabela jest źle zaprojektowana, nie nie ma sensu przechowywał dane klientów w tym wypadku imie i nazwisko razem z zamówieniami. Prawidłowo powinny być minimum dwie tabele jedna Klienci druga Zamówienia w której kluczem obcym było by id_klienta itd..

W tej chwili mam taką tabelę (id_przedmiotu, id_oceny, atrybut1, atrybut2, atrybut3, ocena)
Przykładowy wiersz (23, 12, czerwony, w paski, gładki, 7)

Użytkownicy wskazują 3 cechy danego produktu, a następnie ocenę tego produktu z tymi cechami. Potem jest już grupowanie po cechach i wyliczanie oceny. Czy w takim przypadku również należy to rozbić na dwie tabele?

Pozdrawiam

T800 poproś kogoś o krótki kurs normalizacji bazy danych i jak to powinno mniej więcej wygladać, bo to co robisz w niedługim czasie powróci do Ciebie z tysiącem problemów nie do rozwiązania i będzie trzeba zaczynać projekt od nowa.

Nie za bardzo tez rozumiem czemu chesz mieć wynik 3 skoro zapytanie policzyło ci OK,
chciałeś wiedzieć ile zamówień miała kazda osoba

no chyba ze chodzi ci o

select Liczba fom
(
SELECT `imie`,`nazwisko`,COUNT(*) as Liczba
FROM `zamowienia`
GROUP BY `imie`,`nazwisko`)

Ale o co tu chodzi Ty kierujesz się jakąś logiką w projektowaniu tych tabel czy zasadą, "a może zadziała", a jak nie to spróbuje inaczej... bo na to niestety mi wygląda.

Pewnie chodzi o SELECT COUNT(DISTINCT CONCAT(imie,nazwisko)) FROM zamowienie


Przesadna normalizacja też jest niekiedy przereklamowana Na przykład wyliczanie COUNT(*) w grupach jest dość wolne i lepiej trzymać dodatkowe pole chociaż dane w bazie się mogą przez to "rozjechać"...

Chociaż tabela fakt źle zaprojektowana. Przynajmniej ta pierwsza. Może coś gotowego weź lepiej (przeprojektowanie bazy to raczej napisanie całego projektu od 0 widząc przykład tej 1-ej tabeli )

Dzięki za wskazówkę Sławek, teraz chodzi:)

Co do struktury bazy, tabela z zamówieniami była przykładowa i miała tylko pokazać jaki jest problem. Sama baza wygląda tak:

tabela produkty
(id_produktu, opis)

tabela uzytkownicy
(id_uzytkownika, ...pozostałe dane userów....)

tabela oceny
id_produktu, id_uzytkownika, cecha1, cecha2, cecha3, ocena)

Czy z bazą o takiej strukturze jak wyżej mogą być problemy w przyszłości gdy przybędzie troche rekordów? Teraz wszystkie zapytania i wyniki działąją poprawnie

Pozdrawiam

Nie rozumiem dlaczego dla 3 cech jest jedna ocena ale z bazą nie powinno być problemów. Grunt to żeby tabela ocen była posortowana wzg. tego po czym będziesz wybierał wiersze lub się mieściła w pamięci.