Zapytanie Select do kilku tabel o identycznej strukturze. Opcje

[Niktoś]

Jestem ciekaw ,czy istnieje możliwość utworzyć jedno zapytanie bez join'ów ,union'ów do kilku tabel ,gdzie jest identyczna struktura kolumn.Czy można coś takiego zrobić?
Select * from Tabela1,Tabel2,Tabela3 where mojaKolumna='jakieś dane'

Nazwa kolumny "mojaKolumna" jest taka sama dla wszystkich tabel.

Chyba jest to niemożliwe,szukam już od ponad 3 godzin po google i jedynie co podpowiada to użycie union all.
Wielka szkoda,myślałem ,że tworzenie tabel o podobnych strukturach,będzie pomocne w takich przypadkach.
Teraz będzie ciężko poskładać query stringa z podzapytaniami w zależności od ilości wybranych opcji.

Ten post edytował Niktoś 12.11.2011, 13:16:46

[5k7]

Jeżeli chcesz robić bardziej zaawansowane rzeczy musisz się nauczyć SQL'a w takim stopniu aby budowanie tych zapytań nie było trudnym zadaniem. Poza tym jeżeli masz identyczną konstrukcję tabel to prawdopodobnie przyjmujesz z góry niezbyt dobrą konstrukcję bazy.

Pozdr

[Niktoś]

Tworzenie zapytań same w sobie nie jest trudnym zadaniem,ale robienie zapytań w"locie już tak",gdzie jedno zapytanie ma służyć wielu opcjom ,które użytkownik wybiera.To się nazywa dynamiczne zapytanie do sql'a,i utworzenie go w cale nie jest aż takie proste-szczególnie jak struktura kwerendy jest z podzapytaniami.Owszem można dla każdej opcji zbudować na sztywno kwerende i dać to w np. w switch, ale rozwiązanie takie jest dla mnie trywialne,i można powiedzieć bezużyteczne prz opcji multiwybierania.

Poza tym jeżeli masz identyczną konstrukcję tabel to prawdopodobnie przyjmujesz z góry niezbyt dobrą konstrukcję bazy

Twoje założenie jest jak najbardziej błędne-przynajmniej w moim przypadku-nie wiem skąd u Ciebie takie stwierdzenie?.

Ten post edytował Niktoś 13.11.2011, 19:36:04

[nospor]

Twoje założenie jest jak najbardziej błędne-przynajmniej w moim przypadku-nie wiem skąd u Ciebie takie stwierdzenie?.

Ano stąd, że zazwyczaj, gdy istnieje kilka tabel o identycznej strukturze, to prawdopodobnie ktoś przekomplikował sprawę. Być może faktycznie w Twoim przypadku tak zaprojektowana baza ma sens - niestety nie dowiemy się tego, no chyba, że podzielisz się z nami jak wygląda Twoja baza.

,ale robienie zapytań w"locie już tak",gdzie jedno zapytanie ma służyć wielu opcjom ,które użytkownik wybiera.To się nazywa dynamiczne zapytanie do sql'a,i utworzenie go w cale nie jest aż takie proste

Tutaj również osobiście nie widzę żadnych problemów. Wszystko stałoby się jaśniejsze, jakbyś podzielił się z nami kodem.

[Niktoś]

Ja wiem ,że ma sens i to powinno Wam wystarczyć.Kodu nie podam ,bo wątpię, by ktoś go tutaj zrozumiał.
Odnośnie temat ten nie był na temat mojej struktury bazy i jej sensu-lecz na temat kwerendy select która odwołuje się do kilku tabel o tej samej strukturze kolumn.Pytanie brzmiało czy da rady zrobić to bez podzapytań.Szukałem dość długo na googlach i nie znalazłem dobrego sensownego przykładu ,który byłby odpowiedzią na założony temat("jak najprostsza kwerenda realizująca moje zadania,bez podzapytań")
Problem mój można jedynie rozwiązać poprzez UNION ALL-i tą koncepcję będę musiał realizować -i stwierdziłem ,że będzie trudniej z podzapytaniami, a i na to wymyśliłem rozwiązanie.

Ten post edytował Niktoś 13.11.2011, 20:18:08

[nospor]

Ja wiem ,że ma sens i to powinno Wam wystarczyć

To po grzyba się głupio pytasz

nie wiem skąd u Ciebie takie stwierdzenie?.

skoro i tak nie interesuje cię odpowiedź?

Kodu nie podam ,bo wątpię, by ktoś go tutaj zrozumiał.

Ałć :/

Pytanie brzmiało czy da rady zrobić to bez podzapytań

Tak, ale też się pytałeś

nie wiem skąd u Ciebie takie stwierdzenie

więc ci odpowiedziałem. Więc się teraz nie denerwuj, że jakiś nędzny podnóżek ci na to pytanie odpowiada. Jak cię nie interesuje coś, to się o to nie pytaj (IMG:style_emoticons/default/tongue.gif)

[Niktoś]

Więc się teraz nie denerwuj, że jakiś nędzny podnóżek ci na to pytanie odpowiada

Tego nie powiedziałem ,ani nie pomyślałem.

Byłem tylko ciekawy Dlaczego ten Forumowicz zakłada ,że:

Poza tym jeżeli masz identyczną konstrukcję tabel to prawdopodobnie przyjmujesz z góry niezbyt dobrą konstrukcję bazy

Nie znając konstrukcji ,ani zastosowania mojej bazy.
Ale bardziej interesuje mnie

czy da rady zrobić to bez podzapytań

-takie zapytanie ułatwiłoby mi znacząco sprawę.
Kodu nie podaję,bo piszę w całkiem innym języku niż PHP.
Tak więc nie urażaj się.

Ten post edytował Niktoś 13.11.2011, 20:34:33

[nospor]

Tego nie powiedziałem ,ani nie pomyślałem.

Być może odniosłem mylne wrażenie po tych dwóch Twoich tekstach:

Kodu nie podam ,bo wątpię, by ktoś go tutaj zrozumiał.

Ja wiem ,że ma sens i to powinno Wam wystarczyć

Jak dla mnie zabrzmiało to jak to jaki to ty nie jesteś "ach i och" i wszystko wiesz, a my ciule zwykli banalnej rzeczy nie zrozumiemy (IMG:style_emoticons/default/wink.gif)

Byłem tylko ciekawy Dlaczego ten Forumowicz zakłada ,że:
Cytat
Poza tym jeżeli masz identyczną konstrukcję tabel to prawdopodobnie przyjmujesz z góry niezbyt dobrą konstrukcję bazy

Nie znając konstrukcji ,ani zastosowania mojej bazy.

I ja ci to wyjaśniłem: w 90% procent przypadków na forum taka baza jest wynikiem niewiedzy autora tejże bazy. Jak również napisałem, być może w Twoim przypadku jest inaczej i wyraziłem chęć poznania Twojej bazy z czystej ciekawości.

Kodu nie podaję,bo piszę w całkiem innym języku niż PHP.

I teraz wszystko jasne. Zmieniam zdanie na temat "ach i och" (IMG:style_emoticons/default/wink.gif)

Tak więc nie urażaj się.

Bardziej niż urażony czułem się rozbawiony (IMG:style_emoticons/default/wink.gif) Pamiętaj jednak, że tutaj są nie tylko PHPowcy i nie generalizuj, że nikt z forum nie zrozumie Twojego kodu napisanego w czymś innym niż PHP.

[Niktoś]

Postaram zaspokoić Twoją ciekawość na poniższym przykładzie
<select>
kategoria1
kategoria2
kategoria3
kategoria....n
</select>
Użytkownik wybiera kategorie1 i pobiera dane, modernizuje w zależności od sytuacji z tabeli Kategoria1 .
Każdy jedne użytkownik to 20 wpisów w kategorii którą wybrał.
100 użytkowników to -2000 wpisów.
Czy wyszukiwanie użytkownika po kategorii nie będzie szybsze niż ,branie wszystkich kategorii do jednego wora??
Dajmy na to jak serwis odniesie sukces i będzie miał bardzo dużą popularność Będzie w nim
1000000 użytkowników-to jest 20mil wpisów-wyobrażasz sobie pełnotekstowe wyszukiwanie w takiej ilości danych?
Rozbijając tabelę np na cztery kategorie (będzie znacznie więcej)-to wyszukiwanie użytkownika po jego np nazwie ,czy id przebiegnie znacznie szybciej niż pobierając te dane z jednego wora.
Nawet cieszę się ,że tak zrealizowałem to wszystko,gdyż FTS(ful text search na bazie danych MSSQL)-wymaga aktualizacji indexów(indexowania)-i te indexowanie będzie przebiegać bezboleśnie,niż na jednym wielkim worze w który wszyscy są wepchani.

Ten post edytował Niktoś 13.11.2011, 21:13:54

[nospor]

Dziękuję za zaspokojenie mojej ciekawości (IMG:style_emoticons/default/smile.gif)

Co do problemu:

wyobrażasz sobie pełnotekstowe wyszukiwanie w takiej ilości danych

Sam napisałeś, że podzieliłeś tabele na kategorie. Znaczy, że wyszukiwanie nawet pełnotekstowe i tak robisz po kategorii. W takim razie, nawet jak wszystko będzie w jednym worku, to wyszukiwanie i tak najpierw ograniczysz do kategorii a dopiero niejako potem pójdzie pełnokonktestowe wyszukiwanie.
Przy odpowiednich indeksach takie wyszukiwanie nie powinno być dużo gorsze od wyszukiwania po tabeli podzielonej na 4.

Poza tym, patrząc na pytanie, jakie zadałeś na samym początku widać, że i tak na raz chcesz przeszukiwać kilka tabel (kategorii) więc totalnie bez sensu jest dzielić jedną tabelę na kilka, skoro i tak naraz szukać chcesz we wszystkich

[Niktoś]

Wprowadzam select z muliwyszukiwaniem-osoba będzie mogła wybrać dowolną liczbę kategorii,dodatkowo wprowadzam opcje we wszystkich kategoriach.

Sam napisałeś, że podzieliłeś tabele na kategorie. Znaczy, że wyszukiwanie nawet pełnotekstowe i tak robisz po kategorii

Właśnie przy każdym dodaniu rekordu do kategorii dane będą automatycznie indexowane w tejże kategorii.
Reszta tabel kategorii, będzie wolna od tego procesu.Niestety FTS w MSSQL aby działało poprawnie wyszukiwanie,wymagana jest aktualizacja indexów.

Ten post edytował Niktoś 13.11.2011, 21:23:21

[nospor]

No tak. Czyli zamiast wyszukiwania po jednej tabeli, będziesz miał wyszukiwania po kilku tabelach, będziesz musiał łączyć tabele jednym zapytaniu - może się okazać, że nie jest to wcale szybsze od jendej tabeli.

Warto by przeprowadzic testy (na większej ilości danych, przecież to nie problem takie wygenerować), analizę indeksów itp.

[Niktoś]

Czyli zamiast wyszukiwania po jednej tabeli, będziesz miał wyszukiwania po kilku tabelach, będziesz musiał łączyć tabele jednym zapytaniu

To jest chyba jedyna wada -w tej mojej strukturze i ma ono miejsce tylko w procesie wyszukiwania typu multi-dlatego stąd moje pytanie o kwerendę bez podzapytań,na którą jeszcze nie dostałem odpowiedzi (IMG:style_emoticons/default/sadsmiley02.gif) ,a mówiłeś ,że można -Mógłbyś podać przykład-albo linka?

Ten post edytował Niktoś 13.11.2011, 21:37:48

[nospor]

.Niestety FTS w MSSQL aby działało poprawnie wyszukiwanie,wymagana jest aktualizacja indexów.

Nawet jeśli, to należy się zastanowić co będzie częściej robione: wyszukiwanie, czy aktualizacja danych. Bardzo często przyjmuje się wolniejsze procesy aktualizacji ( nawet dużo wolniejsze) na rzecz szybszych procesów wyszukiwania w przypadku, gdy częściej szukamy/pobieramy niż wkładamy.

a mówiłeś ,że można

Zacytuj mnie, bo nie kojarzę tego faktu. Kojarzę jedynie, iż mówiłem, że nie widzę większego problemu w tworzeniu dynamicznych zapytań do bazy. Mówiłem jednak ogólnie, bo jak pisałem nie wiem jakie ty masz kody u siebie (IMG:style_emoticons/default/smile.gif)

[Niktoś]

Pytanie brzmiało czy da rady zrobić to bez podzapytań

Tak, ale też się pytałeś

nie wiem skąd u Ciebie takie stwierdzenie

Może źle to zrozumiałem, jak tak to idę kleić UNION ALL.

[nospor]

Może źle to zrozumiałem

Źle zrozumiałeś (IMG:style_emoticons/default/smile.gif) Przecież cytowałem Twoje pytanie do 5k7 (IMG:style_emoticons/default/wink.gif)

jak tak to idę kleić UNION ALL.

Czyli jednak Cię nie przekonałem. No nic, szkoda. Mogłeś chociaż porobić testy na większej ilości danych.

[Niktoś]

Ciężko by było wypełniać-gdyż struktura kolumn jest różnorodna.Kolumna typu image ,varchar,bigint-ustawienia ograniczenia długości na varchar'y.-Mógłbym skopiować w pętli rekordy w TSQL- ale nie wiem czy by testy były poprawne,najlepiej by było to robić na różnych rekordach.

[nospor]

Hmm.... za bardzo nie wiem gdzie widzisz problem w wygenerowaniu przykładowych danych? Bo ja nigdzie, nawet dla pól, ktore podałeś.

Możesz dodatkowo w jednej pętli generować od razu dane dla sytuacji z jedną tabelą oraz dla sytuacji z kilkoma tabelami. Dzięki temu obie sytuacje będą operować na tych samych danych, przez co testy powinny być bardziej wiarygodne.

[5k7]

Na wielu tabelach nie bedziesz szybciej przeszukiwał przynajmniej w stopniu dla Ciebie zauważalnym - do tego indeksy - masz różne typy tabel choćby taka jak memory która wymięcie to w moment. Oczywiście trzeba z głową wszystko zrobić. Zresztą jak Ci się serwis rozrośnie i będziesz zarabiał kupę kasy to przesiądziesz się na konkretny serwer/y + oracle (IMG:style_emoticons/default/wink.gif) i wówczas będziesz miał doładowanie wydajnościowe.

Pozdr

Ten post edytował 5k7 14.11.2011, 10:06:10

[prachwal]

Ja wiem ,że ma sens i to powinno Wam wystarczyć.Kodu nie podam ,bo wątpię, by ktoś go tutaj zrozumiał.
Odnośnie temat ten nie był na temat mojej struktury bazy i jej sensu-lecz na temat kwerendy select która odwołuje się do kilku tabel o tej samej strukturze kolumn.Pytanie brzmiało czy da rady zrobić to bez podzapytań.Szukałem dość długo na googlach i nie znalazłem dobrego sensownego przykładu ,który byłby odpowiedzią na założony temat("jak najprostsza kwerenda realizująca moje zadania,bez podzapytań")
Problem mój można jedynie rozwiązać poprzez UNION ALL-i tą koncepcję będę musiał realizować -i stwierdziłem ,że będzie trudniej z podzapytaniami, a i na to wymyśliłem rozwiązanie.

ja trzaskam TSQL-a (IMG:style_emoticons/default/smile.gif) i powiem że masz kretyńską bazę danych - tak się nie projektuje struktur danych

a co do meritum

;with dupa as (
select * from tabela
), dupa2 as (
select * from tabela_2
)

select dupa.* from dupa join dupa2 on dupa.id = dupa2.id

nie napisałeś czy chcesz podzapytanie zwykłe czy skjorelowane