Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Zapytanie warunkowe?
Forum PHP.pl > Forum > PHP
Hazel
Witam.
Moja struktura bazy jawi się tak:

tabela X (id, type (pole typu ENUM o możliwych wartościach t lub n lub g), nieistotna_kolumna1, nieistotna_kolumna2...)

tabela T (id, jakieś tam kolumny)
tabela N (id, jakieś tam kolumny)
tabela G (id, jakieś tam kolumny)

Tworzę zapytanie SELECT, które ma pobierac dane z odpowiedniej tabeli T lub N lub G, w zależności od wartosci type dla danego id. Da się to zrobić jednym zapytaniem poprzez łączenie tabel w jakiś sposób? Zupełnie nie mam pomysłu.

Oczywiście, nie musi być jednym zapytaniem - ale możliwie najwydajniej. Żeby nie trzeba było pobierać wartości type do php i w zależności od tej wartości robić trzech różnych zapytań... No, chyba że nie da się inaczej.

Proszę o pomoc i pozdrawiam.
mysz0n
nie lubie takich przykładów a,b,c,x wiec zakładam ze pola enum to pola: ksiazki, plyty_cd, filmy_dvd, do tego masz tabele z wieksza iloscią informacji odnośnie tych trzech rezczy, dajmy na to ze ktos klika u ciebie button z filmami_dvd i ty generujesz pytanie

  1. SELECT * FROM '$to_co_kliknal_user';

i jest.

chyba ze chodzi ci o jakies proste łączenie tabel w stylu
  1. WHERE x.typ = g.id
?

jesli nie chodzi o to to napisz jakos jasniej na bardziej 'życiowych' przykładach, wtedy zawsze jakoś łatwiej mi sie myśli nad ew. innym rozwiazaniem:)
Hazel
Cytat(mysz0n @ 18.01.2008, 01:18:08 ) *
chyba ze chodzi ci o jakies proste łączenie tabel


Tak, chodzi raczej o łączenie tabel. Czy proste - nie mi to oceniać, wszystko jest proste, jak się potrafi to zrobić, ja nie potrafię, więc dla mnie to trudne winksmiley.jpg

No to tak. Mam obiekt, który można nazwać koszykiem (koszykiem nie jest do końca, spełnia jednak podobną funkcję). Każdy użytkownik ma swój koszyk. W koszyku ma jakieś przedmioty. Powiedzmy, że użytkownik o id 1 ma 2 książki, 2 płyty cd i film dvd. Oznacza to, że rekordy tabeli X (czy, jak wolisz, tabeli PRZEDMIOTY) wyglądają tak:
Kod
id_przedmiotu typ_przedmiotu id_użytkownika
1 książki 1
2 książki 1
3 płyty_cd 1
4 płyty_cd 1
5 filmy_dvd 1


Załóżmy, że istnieje jeszcze czwarty rodzaj obiektów, na przykład czasopisma. Jak widać, w przykładzie użytkownik 1 nie ma żadnego czasopisma w koszyku. Przejdźmy dalej.
Mam tabele typy_książek, typy_płyt_cd, typy_filmów_dvd, typy_czasopism. W nich znajdują się szczegółowe informacje o danym rodzaju przedmiotów. Chcę je po prostu wyciągnąć. Ale w taki sposób, by nie angażować niepotrzebnie tabeli typy_czasopism, jeśli w koszyku nie ma żadnego czasopisma. To chyba dość ambitne, żeby zrobić to w jednym zapytaniu - dla mnie zbyt ambitne. No bo kilkoma zapytaniami to nie problem - if ($row['typ_przedmiotu']=='książki'){[zapytanie do tabeli typy_książek]} else if(...) itd. Mam nadzieję, ze wytłumaczyłem to dobrze. Liczę, że jedno zapytanie działałoby do kilku razy szybciej (w skrajnych przypadkach, kiedy dany użytkownik ma w koszyku wszystkie rodzaje przedmiotów, to nawet do kilkunastu razy) niż pobieranie typu obiektu z każdego rekordu, sprawdzanie go w php, wysyłanie kolejnego zapytania, i tak aż do końca tyle razy, ile jest tabel typów, więc sądzę, że gra jest jednak warta świeczki. Proszę o pomoc.

P.S. Strukturę bazy chciałbym zmienić tylko w ostateczności. Zdaję sobie sprawę, że dla podanego przykładu struktura jest daleka od optymalnej, ale to jest tylko jeden z wielu modułów całego projektu - baza ma znacznie więcej tabel i jest przeznaczona do znacznie wiekszej ilości zadań. Dlatego chciałbym ją modyfikować tylko w ostateczności - jestem skłonny to zrobić, jeśli ktoś zaproponuje naprawdę o niebo lepsze rozwiązanie, ale wolałbym nie, bo to niesie za sobą gigantyczne przeróbki w reszcie kodu. Więc najlepiej by było, gdyby potencjalne rozwiązanie dotyczyło takiej struktury bazy.
Pozdrawiam.
mysz0n
szczerze mówiąc tabele w bazie wydają mi sie niestety - nie optymalne. optymalnośc chyba zawsze polega na jaknajlepszym zaprojektowaniu bazy, wiesz jak ja bym zrobił? zostawił tabele w której są wybrane przedmioty przez usera, i zrobił 2 table - zamiast tych 3 (T,N,G).
mianowicie tabela PRODUKTY | id_prod | id_kategorii | opis | cena | informacje_dodaktowe | inne_kolumny | przykładowy wpis w tej tabeli wyglada tak (1,1,jakis opis, 50zł,xxx,yyy)

i 2. tabela KATEGORIE | id_kategorii | nazwa_kategorii | w tej tabeli maiłbys dane w stylu (1,książka), (2,plyty_dvd)
zachowujesz rozszerzalnosc - bo jak rozumiem teraz dodajesz czasopisma - i musisz dodac nową tabele do tabel T,N,G, i tam wrzucic czasopisma - co jest słabe, bo od ilosci kategorii bedzie zależała ilośc tabel? prowadzac wiekszy sklep mogłbys miec kilkadziesiat tabel a w kazdej po 10 wpisów.
a tak - dodajesz nową kategorie do tabeli - kategorie i spoko.do koszyka dodajesz produkty poprzez id_produktu, a nazwe kategorii wyciagasz poprzez takie zapytanie.

  1. SELECT * FORM produkty p, kategorie k
  2. WHERE k.id_kategorii = p.id_kategorii


nie ma w tym nic złego, że miałbyś nawet 100tysiecy produktów z różnych kategorii w jednej tabeli.
jesli to nie pomogło - daj znac, cos innego wymyślimy snitch.gif
Hazel
Cytat(Hazel @ 19.01.2008, 09:04:54 ) *
Zdaję sobie sprawę, że dla podanego przykładu struktura jest daleka od optymalnej



Cytat(mysz0n @ 20.01.2008, 13:38:23 ) *
szczerze mówiąc tabele w bazie wydają mi sie niestety - nie optymalne.


No to jesteśmy zgodni. Tyle że ja nie poszukuję optymalnej struktury bazy, a bardziej zapytania, które przy istniejącej strukturze pozwoli mi wyciągnąć potrzebne mi dane. Głównie dlatego, że projekt jest juz dość rozbudowany i każda, nawet drobna, zmiana struktury powoduje daleko idące modyfikacje kodu, a to pochłania czas i pracę. Dlatego rad bym był, gdyby ktoś znalazł takie rozwiązanie, jakiego ja poszukuję, a nie substytucyjne. Co oczywiście w niczym nie umniejsza Twojej chęci pomocy - powiem Ci więcej - przemyślę tego posta i być może wprowadzę te poprawki, które proponowałeś, jeśli wydadzą mi się lepsze całościowo dla projektu, ale muszę to 15000 razy rozważyć.
Pozdrawiam.

P.S. Ten sklep to tylko przykład, cała aplikacja polega zupełnie na czym innym, dlatego nie sugeruj się do końca tymi kategoriami - bo to działa podobnie jak koszyk, kategorie produktów i użytkownicy którzy je mają, ale jednak inaczej i Twoje rozwiazanie nie bardzo pasuje. Może coś z tego zrobię, jednak wolałbym, gdyby ktoś tutaj niezobowiązująco odpowiedział bezpośrednio na pierwszy post winksmiley.jpg

edit: Przyswoiłem sobie to, co do mnie napisałeś. Nie, nie mogę tak zrobić, bo tabele T, N i G mają zupełnie inne struktury. Fakt, że dla sklepu interentowego właściwości byłyby podobne - każdy obiekt ma cenę, ma jakies inne podobne właściwości, ale moje obiekty T, N i G różnią się od siebie... Dałoby się na to zaradzić w taki sposób, żeby nie było masy pustych pól? A faktycznie pomysł, żeby było tyle tabel ile kategorii jest lipny - tutaj masz rację, po prostu nie miałem lepszego...

edit2: powiedzmy, że mam tak: w tabeli T, N i G mam dwie kolumny wspólne i po dwie, które są indywidualne dla kązdej z tych tabel... Robić jedną tabelę wspólną z ośmioma polami, z których 4 zawsze w każdym rekordzie są puste? Chyba się nie oplaca...

edit3: rozważyłem wszystkie możliwości, wpadłem na pewien pomysł, jak mi się zechce go opisać to będzie edit4 jutro tongue.gif na razie rozwiązane, choć proszę nie zamykać smile.gif
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-2025 Invision Power Services, Inc.