[SQL] Wyświetlanie rekordów Opcje

[sadistic_son]

Mam 2 tabele w bazie:

Wiadomosci:
id_w
od_kogo
do_kogo
tekst

Userzy:
id_u
nazwa

Kiedy user wysyła wiadomość (np. user o nazwie AAA i id=1 do usera BBB o id=2) to w tabeli wiadomości zostanie dodany rekord o wartości pól: od_kogo=1 i do_kogo=2:

[SQL] pobierz, plaintext 
INSERT INTO wiadomosci VALUES( NULL , '1' , '2' , 'tekst' )
[SQL] pobierz, plaintext 

Moje pytanie brzmi jak wyświetlić te wiadomości tak aby zamiast id userów pojawiły się ich nazwy. Normalnie nie miałem z tym problemów bo robiłem to tak:

[SQL] pobierz, plaintext 
SELECT userzy.nazwa , wiadomosci.tekst FROM wiadomosci , userzy WHERE userzy.id = wiadomosci.od_kogo
[SQL] pobierz, plaintext 

Ale tutaj jest problem bo przecież pola od_kogo i do_kogo oba są wartościami id z tabeli userzy. Jak skonsrtuować zapytanie aby SQL nie zgłupiał?

[thek]

To może jako ciekawostkę dodam, że w systemach DB2 by przyspieszyć wykonywanie zapytań, niejawnie SELECTy w podzapytaniach są konwertowane do JOINa odpowiedniego. Jeśli coś takiego robi IBM to jak myślisz, czy inni twórcy silników bazodanowych nie robią podobnie by osiągnąć lepszą wydajność? Może się więc okazać, że choć nasze zapytania są od strony usera różne, to po stronie bazy mogą być albo niemal identyczne, albo identyczne wręcz i nasza debata jest tak naprawdę mało istotna. Oczywiście na pewno dzieje się to w określonych przypadkach, a nie zawsze. Ale daje to ciekawą podstawę pod dalszą dyskusję na temat sensowności optymalizacji (IMG:style_emoticons/default/winksmiley.jpg) Lepiej pisać jawnie JOIN, czy zdać się na silnik i konwersję niejawną między subquery a JOIN. O tej ciekawostce przeczytałem w necie i byla ona ponić efektem korespondencji z inżynierem IBM, gdy zapytano go o wydajność pomiędzy subquery i join w DB2 i powiedzial on tam o znikomej różnicy, ze względu właśnie na niejawna konwersję zapytania.
Od momentu rejestracji w tematach widziałem bowiem wiele nieoptymalizowanych zapytań, gdzie ludzie używali ewidentnie niewłaściwych, stworzonych zapewne na podstawie tutoriali netowych bez zrozumienia ich sensu. Sam nieraz bylem zmuszony używać subqueries, bo nie zawsze jest możliwe zastosowanie join, choćby w sytuacjach gdy musimy użyć odpowiedniego WHERE pole IN. Jeśli jednak silniki bazodanowe w dużej mierze mają zaimplementowaną konwersję podzapytań do join, to może się okazać, że w większości przypadków spór "subqueries vs join" jest podobny do wyższości wielkiej nocy nad bożym narodzeniem (IMG:style_emoticons/default/biggrin.gif) A narzut mały i niemal brak różnic jest związany właśnie z niejawną konwersją :] Może jednak to się wydzieli jako osobny wątek w optymalizacji? (IMG:style_emoticons/default/snitch.gif)

Ten post edytował thek 23.08.2009, 17:11:36