Witam!
Mam przykladowe tabele:

tabela1
- id
- imie

tabela2
-id
-zapalcil


W tabeli1 mam wszystkich użytkowników serwisu. W tabeli2 mam tylko id użytkowników co zapłacili. I teraz czy to możliwe odczytać za pomocą samego zapytania tych ludzi co nie maja oppaconego abonamentu a sa w serwisie czyli wszytkich userów znajdujacych sie w tabeli1 z wylaczeniem userow w tabeli2??

Probowałem tak ale to nie idzie:

[SQL] pobierz, plaintext 
SELECT DISTINCT tabela1.id, tabela2.id FROM tabela1 INNER JOIN tabela2 ON tabela1.id = tabela2.id
[SQL] pobierz, plaintext 

Wypisuje mi to wszytkich nie odrzuca userow z tabeli2

Może ma ktoś jakiś pomysł Chciałbym to zrobić na poziomie MySQL.

spróbuj tak:

[SQL] pobierz, plaintext 
SELECT DISTINCT tabela1.id, tabela2.id FROM tabela1 INNER JOIN tabela2 ON tabela1.id<>tabela2.id
[SQL] pobierz, plaintext 

Mozesz tak:

[SQL] pobierz, plaintext 
SELECT * FROM tabela1 LEFT JOIN tabela2 ON tabela1.id = tabela2.id_tabeli1 WHERE tabela2.id IS NULL
[SQL] pobierz, plaintext 

Wielkie dzięki!!! Śłicznie zadziałało.

[SQL] pobierz, plaintext 
SELECT * FROM tabela1 LEFT JOIN tabela2 ON tabela1.id = tabela2.id_tabeli1 WHERE tabela2.id IS NULL
[SQL] pobierz, plaintext 

to jest prawidlowe rozwiazanie

a nie prosciej tak?

[SQL] pobierz, plaintext 
SELECT * FROM tabela1 WHERE id NOT IN (SELECT id FROM tabela2)
[SQL] pobierz, plaintext 

Z tego, co pamiętam, to zapytania z IN są wolniejsze.

bardzo mozliwe, ale nie popadajmy w paranoje. Nie wnikam czy bedzie to rzad wielkosci 0.0x, 0.00x czy jeszcze mniejszy ulamek sekundy sekundy. Serwera to nie zarznie a po co sobie utrudniac zycie, im prostsze zapytanie tym mniejsza mozliwosc zrobienia pomylki. Tabele i tak nie sa optymalnie zaprojektowane wiec wydajnoscia az tak bardzo bym sie nie stresowal

Dobra, przy kilku odwiedzinach, ok.

Ale co w sytuacji, gdy masz powiedzmy tylko te 20 żądań i słabszy serwerek. Sam skrypt wykonuje np. 10 zapytań. Wtedy te setne części sekund musisz przemnażać 10^N, w zależności jaki serwer, ile żądań jednocześnie...

Grosik do grosika, tutaj - sekunda do sekundy i wyjdzie na to, że cały skrypt jest do wyrzucenia/do przepisania, bo działa za wolno.

Kiedyś programiści mieli ograniczone zasoby sprzętowe i pisali wszystko na miarę bardziej ceniąc sobie wydajność, a nie wygodę (i często potrafili te obie rzeczy ze sobą pogodzić).

A teraz co? Zdziwienie, gdy przychodzi mail od administracji proszę zoptymalizować zapytania do bazy.

a czym ta administracja administruje? serwerem na 486? jesli takie zapytanie przeciazy im serwer to chcialbym zobaczyc jak dziala tam chociazby phpbb by przemo :]

a mowiac serio to nie caly skrypt do przepisania tylko zapytanie, albo inaczej - pierwsza tabela do przerobienia w ten sposob
- id
- imie
- zaplacil

i wszystko

No, swego czasu była afera z home.pl... (choć to może zły przykład)

Ale kiedyś czytałem, że podobne sytuacje miały miejsce u innych ISP-ów własnie przy zbyt "żrących" zapytań i nie były to "Przema".

Odnosnie wydajnosci czy IN czy LEFT JOIN wszystko zalezy od zlozonosci i wielkosci rekordow nie ma sensu przekownywac sie co jest lepsze. Jesli wydajnosc jest nieodpowiednia testy i modyfikacje zapytania w celu polepszenia. Jak bedzie 10 rekordow to nawet zapytanie z 10 podzapytaniami moze byc trafnym rozwiazaniem.