[MySQL] Traktowanie kliku takich samych tabel jak jedną

Odpowiedz Nowy wątek
2006-10-02 00:22
0

Mam tabelę X, którą porozbijałem na tabele: X1, X2, X3, ... Chcę dać SELECTa z tych tabel, ale w ten sposób, by wyciągnąć wyniki z tabel X1, X2, X3. Jeśli dam SELECT * FROM X1, X2, X3 WHERE user=1; to nie spełni swojego rezultatum gdyż dane śie pogrupują, potroją, itp. Chodzi mi o to, by każdy rekord był wybierany raz, czyli, by te trzy tabele były traktowane jak jedna. Jakie zapytanie byłoby potrzebne do tej sytuacji?

Przykład:
X1:
imie user
Tomek 1

X2:
imie user
Adam 1
Ewa 2
Ela 1

X3:
imie user
Michal 3
Julek 1

Chcę jednym zapytaniem wyciągnąć 4 wiersze, gdzie user=1.

Z góry dziękuję


Pozostało 580 znaków

2006-10-02 17:35
0

A miałem taki problem z wyświetlaniem w ten sposób danych. Bodajrze udało mi się to zrobić. Poszukam. moje gg 5144799

Pozostało 580 znaków

2006-10-02 18:11
0

Słowo kluczowe UNION do połączenia 4 osobnych selektów w jedną odpowiedź.


<font color="red">Konto porzucone</span>

Dzięki wszystkim forumowiczom za lata wspólnych dyskusji; miłej zabawy w programowanie!
Sławomir 'Szczawik' Włodkowski

Pozostało 580 znaków

2006-10-05 19:35
maniek_2
0

Nie robi sie kilka tych samych tabel. Bezsens.

Pozostało 580 znaków

2006-10-06 00:49
0

Maniek, a czemu nie? Czasem jest to bardzo dobre rozwiązanie. Przykład: Mamy sklep internetowy i w nim przedmioty, które są lub były sprzedawane. I teraz wszystkie, których nie ma w magazynie przerzucasz do drugiej tabeli (o identycznej strukturze), by wyświetlanie wśród tych aktualnych było szybsze (zakładając, że tych nie występujących jest dużo więcej niż tych będących akurat na stanie). Jednak czasem ktoś chce znaleźć jakiś przedmiot niezależnie od tego, czy jest w sprzedaży, czy nie, więc ma taką możliwość (właśnie takie scalenie wyników).


Grunt to uziemienie...

Pozostało 580 znaków

2006-10-06 09:36
maniek_2
0

A nie lepiej poprstu wprowadzić odpowiednie pole, które oznacza czy dany przedmiot został juz zakupiony? Wtedy aktuazliujesz tylko jedno pole a nie "transferujesz" danych do kolejnej o takiej samej budowie tabeli. Ze sklepem problem jest szerszy, gdyz trzeba zwrócić uwagę, że ceny przedmiotów się mogą zmieniać w czasie. Dlatego najczęściej tworzy się tabele t.zw. historii zakupu, gdzie właśnie w niej są informacje jaki towar został zakupiony (klucz obcy do danego towaru), cena zakupu oraz osoba, która to kupiła. I oczywiście jak istnieje odniesienie na zasadzie klucza własnego i obcego dla zakupionego towaru tak i istnieje odniesienie do tabeli osób, które zakupili, np:

tab_osoba:
id_osoba | imie | nazwisko | id_adresu

historia_zakupu:
id_historii | id_towaru | cena | data_sprzedazy | id_osoba

towar:
id_towaru | nazwa | cena

Oczywiście do tabeli towarów mozna dodać kolejną kolumne oznaczającą czy jeszcze towar jest na stanie albo ilość tego towaru, która to ilość będzie zmniejszana bądź dodawana (w przypadku zakupu towaru do sklepu).

Pozostało 580 znaków

2006-10-06 09:40
maniek_2
0

Dodatkowo przecież istnieją w bazach widoki (wirtualne tabele) na zasadzie których można stworzyć odpowiednie filtrowanie danych.

Pozostało 580 znaków

2006-10-17 12:11
0

maniek_2: Można stworzyć takie pole. Ale nie nazwałbym tego lepszym rozwiązaniem - dzięki transferowi danych (tylko raz na każdy przedmiot!) można operować na o wiele mniejszej tabeli (w grę wchodzą miliony rekordów), kiedy nie potrzebujemy historii.


Grunt to uziemienie...

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0