Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Dublowanie zapytania w UNION ALL?
Niktoś
post 25.03.2012, 15:40:43
Post #1





Grupa: Zarejestrowani
Postów: 1 195
Pomógł: 109
Dołączył: 3.11.2011

Ostrzeżenie: (10%)
X----


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.

Ten post edytował Niktoś 25.03.2012, 15:44:44
Go to the top of the page
+Quote Post
mortus
post 25.03.2012, 16:05:59
Post #2





Grupa: Zarejestrowani
Postów: 2 178
Pomógł: 596
Dołączył: 25.09.2009
Skąd: Piwniczna-Zdrój

Ostrzeżenie: (0%)
-----


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ć.

Ten post edytował mortus 25.03.2012, 16:13:33
Go to the top of the page
+Quote Post
Niktoś
post 13.04.2012, 17:46:33
Post #3





Grupa: Zarejestrowani
Postów: 1 195
Pomógł: 109
Dołączył: 3.11.2011

Ostrzeżenie: (10%)
X----


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.

Ten post edytował Niktoś 13.04.2012, 18:01:42
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 25.04.2024 - 09:34