MySQL 4.1-en kell dolgoznom, és a következõ a probléma:

SELECT id,cim,
      (SELECT COUNT(*) FROM iromany WHERE szulo=iromany_kategoria.id), –AS entrynum
      (SELECT datum FROM iromany WHERE szulo=iromany_kategoria.id ORDER BY datum DESC) –AS datum
FROM iromany_kategoria ORDER BY (SELECT datum FROM iromany WHERE szulo=iromany_kategoria.id ORDER BY datum DESC) DESC;

Valami ilyesmi kellene, csak nem megy… üreset ad vissza, pedig nem kellene neki. Egy view-szerûséget akarok megvalósítani, csak nem megy jól…

Az a baj, hogy a subquery szintaxisa nem elég világos elõttem, azaz, hogyan lehetne mysql-lel view-szerû query-ket csinálni…

Bocs! – nem is tudtam mit indítottam el … ;o)
Nos, ami szerintem a legfontosabb, a mysql csak az innoDB táblákkal tusd tranzakcionális kezelést (commit/rollback), nem ismeri a referencia integritést, azaz a porogramnak magának kell ellenõríznie pl. a kulcsok egyediségének feltételeit ill. a relációs kapcsolatok kulcsainak megfelelõségét. Gyakorlati tapasztalat szerint az adatbázis növekedésével egyre lassabb a motor (amit én láttam egy év után szinte használhatatlan pedig nincs benne 1 mill rekord – ennél sokkal nagyobb adatbázisokat kezelek  – nem SQL és nem kliens/szerver mégis flottul szalad, hasonló kaliberû gépeken, tény hogy itt menden binárian tárolódik és néhány trükköt is bedobok).
A postgre ezektõl a hibáktól hiányosságoktól mentes, azaz alapból van tranzakció kezelés, relációs adatbázis kulcsainak ellenörzése (számlafej/tétel példánál, nem enged olyan tételt insertálni aminek nincs feje). Azonban ha tényleg megtervezed és beviszed ezeket a szabályokat az adatbázis táblákba akkor sok bonyodalom érhet, amit a mysql -nál észresem veszel amíg tételesen nem kezded el átfésülni az adatokat! Ha erre nem készülsz fel, akkor sok bajod lessz, pedig csak egy szigorúan ledefiniált adatbázisod van. Ki ois hagyhatod ezeket, sõt a fejlesztési stádiumban még gyorsabban is tudsz haladni, és csak akkor „húzod rá” az adatbázisodra ezt a „nessus” inget amikor termék lessz – persze egy komplett ellenörzés kell.
Ami view kontra join dolgokat illet mindenképpen a view -ra szavazok a gyakori lekérdezéseknél, mindezt persze „megpatkolnám” azzal hogy a felhasználó legfontosabb adatait igenis beépíteném a hozzászólásaiba, méghozzá a bejelentkezéskor cachel-t rekordból, persze ha a sebesség a fõ cél!
Az egyszerû programozásnál is áll a dilemma, hogy több kód/adat nagyobb sebesség vagy kevesebb kód/adat kisebb sebesség, ez alapvetõen az egyidejûleg benntartott rekordokra vonatkzik, ill. a redundáns adatok tárolásában is jelentkezik.
Ami a netes adatbázis alkalmazást illeti abban tökéletesen egyet értünk hogy az eredmény a fontos hiszen az sokkal több mint egy-egy lekérdezés és még mindíg a sávszélesség gondok vannak, viszont azért a motor reakció sebességével is számolni kell, azaz ha túl sokat kell „mókolnia” az sem jó! Itt jönnek a mérnöki szempontok és a megfelelõ kompromisszum megtalálása.

Hali xcut…

Szóval az lenne neked a lényeg, hogy 2 különbözõ táblából nyert query adatait egyesítsd egyetlen queryvel?
Ezt vhogy így csinálnám meg (nincs fent jelenleg a mysql-emben tartalom, szal nemtom érdemileg tesztelni, de ötleteket szeretnék adni)

Ilyet is lehet: kiválasztja azokat a sorokat a tabla1-bõl, amiknek az ize0 oszlopa egyezik a tabla2 bármelyik sorának ize5 oszlopával:

Ezt persze lehet szigorítani:

Ha jól értem, te a tabla1-bõl akarsz kiválasztani néhány oszlopot