Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Dublowanie zapytania w UNION ALL?
Forum PHP.pl > Forum > Bazy danych > Microsoft SQL Server / MSDE
Niktoś
Witam po zaznaczeniu pewnej opcji dubluje mi się rekord.Sama kwerenda jest generowana automatycznie.
Zapytanie wygląda tak:
  1. SELECT p.[IdP],p.[PRegon],p.[pTypSklepu],p.[NazwaProduktu],p.[DostepnaIlosc],p.[StanProduktu],p.[CenaBrutto],p.[Obraz1] FROM [AGD/RTV] p JOIN tSklepS d ON d.Wojewodztwo=@Param5 AND p.PRegon=d.regon WHERE CONTAINS ([NazwaProduktu],@Param) AND p.StanProduktu=@Param2
  2. UNION ALL
  3. SELECT p.[IdP],p.[PRegon],p.[pTypSklepu],p.[NazwaProduktu],p.[DostepnaIlosc],p.[StanProduktu],p.[CenaBrutto],p.[Obraz1] FROM [ELEKTRONIKA] p JOIN tSklepS d ON d.Wojewodztwo=@Param5 AND p.PRegon=d.regon WHERE CONTAINS ([NazwaProduktu],@Param) AND p.StanProduktu=@Param2
  4. UNION ALL
  5. SELECT p.[IdP],p.[PRegon],p.[pTypSklepu],p.[NazwaProduktu],p.[DostepnaIlosc],p.[StanProduktu],p.[CenaBrutto],p.[Obraz1] FROM [KSIĘGARNIA] p JOIN tSklepS d ON d.Wojewodztwo=@Param5 AND p.PRegon=d.regon WHERE CONTAINS ([NazwaProduktu],@Param) AND p.StanProduktu=@Param2
  6. UNION ALL
  7. SELECT p.[IdP],p.[PRegon],p.[pTypSklepu],p.[NazwaProduktu],p.[DostepnaIlosc],p.[StanProduktu],p.[CenaBrutto],p.[Obraz1] FROM [MEBLOWY] p JOIN tSklepS d ON d.Wojewodztwo=@Param5 AND p.PRegon=d.regon WHERE CONTAINS ([NazwaProduktu],@Param) AND p.StanProduktu=@Param2
  8. UNION ALL
  9. SELECT p.[IdP],p.[PRegon],p.[pTypSklepu],p.[NazwaProduktu],p.[DostepnaIlosc],p.[StanProduktu],p.[CenaBrutto],p.[Obraz1] FROM [MOTORYZACJA] p JOIN tSklepS d ON d.Wojewodztwo=@Param5 AND p.PRegon=d.regon WHERE CONTAINS ([NazwaProduktu],@Param) AND p.StanProduktu=@Param2

Szukałem bugu u siebie w skrypcie i nadal mam wątpliwości,gdyż użyłem samo UNION i rekordy nie zostały zdublowane,jednakże patrząc na zapytanie każdy Select po union ALL tyczy się innej tabeli.Czy to może być wina złączenia join?Czy to w ogóle jest wina kwerendy?Nie mogę dopatrzyć się przyczyny dublowania rekordu.Jeśli zdecydowanie wina kwerendy jakbym mógł ją przerobić,tak aby rekordy się nie dublowały,pozostawiając przy tym dyrektywę UNION ALL.Z góry dziękuję za pomoc.
mortus
Wygląda na to, że jest to wina złączeń, ponieważ warunki złączenia są w każdym przypadku identyczne. Nie znam jednak całej architektury bazy danych, choć po tym fragmencie widzę, że nie trzyma się ona kupy. Każda kategoria produktu to inna tabela z identycznymi polami jak inne?! Kto to projektował?

Ciężko powiedzieć co dokładnie jest nie tak i nie wiem, czy komuś będzie się chciało to analizować, tym bardziej, że jak na mój gust baza danych jest źle zaprojektowana.

EDIT:
Zastosowanie klauzuli UNION zamiast UNION ALL daje oczekiwany rezultat, ponieważ UNION sumuje zbiory bez powtórzeń (DISTINCT).
A jesteś pewien, że dwa jednakowe produkty nie są podpięte pod dwie różne kategorie, przecież pomiędzy ELEKTRONIKĄ a np. RTV/AGD nie ma większej różnicy, a przynajmniej nie musi być.
Niktoś
Mówisz ,że to wina join ,kurcze też tak myślę- to jest warunek wyszukiwania po województwie -jak ktoś zaznaczy to rekord się dubluje.Jakby można tego uniknąć Order By/Dinstinct w złączeniu join?
Cytat
A jesteś pewien, że dwa jednakowe produkty nie są podpięte pod dwie różne kategorie, przecież pomiędzy ELEKTRONIKĄ a np. RTV/AGD nie ma większej różnicy, a przynajmniej nie musi być.

Raczej nie ale jeszcze to sprawdzę(Sprawdziłem i Nie)

Dobra znalazłem coś lepszego od Union i Left join -EXCEPT -narazie testowałem to u siebie i nie duplikuje:).Zostawię to i zobaczę czy zda egzamin.

EXCEPT:
Cytat
It returns all the distinct rows in the first query that are not returned in the second query. The queries that use EXCEPT operator must have same number of columns and the order of the columns should also be the same and their data types should be compatible.

Chyba pasuje jak ulał do mojego schematu.

Cytat
Każda kategoria produktu to inna tabela z identycznymi polami jak inne?! Kto to projektował?
Ciężko powiedzieć co dokładnie jest nie tak i nie wiem, czy komuś będzie się chciało to analizować, tym bardziej, że jak na mój gust baza danych jest źle zaprojektowana.


W przypadku wyszukiwania takie założenie ma swoje plusy i minusy.Plusem jest w przypadku wyszukiwania w pojedynczej kategorii,produkty jakiegoś sklepu przykładowo w AGD/RTV,wyszukiwanie będzie tylko w tej tabeli i będzie szybsze niż gdybyś miał wszystko w jednym woru.Minus kiedy ktoś przeprowadzi złożone zapytanie tzn.będzie wyszukiwał spośród wielu kategorii.To będzie trwało dłużej.Schemat mojej bazy pozwala na jej łatwą administracje i archiwizacje.Archiwizuje jedną tabelę konkretnego działu/kategorii,dokonuje modernizacji na jednej tabeli np. w panelu administratora delete/update/insert będzie o wiele szybszy-zaznaczam kategorie i wyszukuje użytkownika pozostawiając resztę kategorii w spokoju(nie miele wszystkiego na raz jak to ma miejsce w standardowych schematach).Mało tego mogę autoryzować prawa użytkownika na tą tabelę ,którą użytkownik aktualnie użytkuje.Użytkownik w agd/rtv będzie mógł dokonywać standardowych operacji na tej tabeli ,ale np.w dziale elektronika i innych będzie blokada na insert/update/delete.Jak jakiś wścibski jakimś sposobem rozwali mi tabele to konkretnego działu a nie wszystkich.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.