Második sőt, az elsőt amikor meglátom hányni tudnék, de abszolút egyénfüggő.

Én kérek elnézést!

én is így vagyok vele, zavarja a szemem

Life is too short to stay stock!

Köszönöm a választ mindenkinek. Nekem is a JOIN szimpatikusabb egyébként, formailag legalábbis.

[ Szerkesztve ]

Nekem egyetemen a 2.-at (JOIN-ok) oktatták, munkahelyen az 1.-t használjuk. Szerintem aki teljesen kezdő SQL-ben, annak könnyebben rááll az agya az 1. verzióra, mert ott az egyenlőségjelen kívül (+) jelöli a gyenge kötést, míg a 2. verzióban LEFT, RIGHT, OUTER stb. kulcsszavak is használandóak. Az 1. verzió egyetlen hátránya, hogy a FULL OUTER JOIN-t nem lehet szépen megvalósítani (UNION kell hozzá). Ebben az egy esetben használom én is inkább a JOIN-t.

Ja, és fórumtársak írták, hogy nekik a JOIN sokkal átláthatóbb, mert egyből látszik, hogy mi hova kapcsolódik. Ez igaz, de ha tucatnyi tábla van összekapcsolva, akkor talán jobb, ha előbb látszik, hogy egyáltalán milyen táblákat használ a lekérdezés (1. verzióban FROM után a legtöbb tábla felsorolásra kerül). Ha az ember az ideje 90%-ában ugyanazokkal a táblákkal dolgozik, akkor úgyis fejből tudja a kapcsolatokat.

Attól eltekintve, hogy a 2.-ból kimaradt az "e".
SQL server függő. Egyszerű példánál talán nincs jelentősége. Performancia szempontjából pedig több kell ennél. Ezt magad is megnézheted, ha az execution times figyeled vagy execution plan-t, hogy mi lesz belőle.

“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”

Sziasztok!

Adott ez az adatbázis:

és ezt a két SQL lekérdezést kéne megírni hozzá:
A kiválasztott alapanyag mely ételekben szerepel, a kiválasztott étel receptje.
Nagyon hálás lennék ha segítenétek!

[ Szerkesztve ]

Ez suliban a vizsgaadatbázis kb 4 éve de nekem nem nagyon megy az SQL Ezért kértem itt segítséget

[ Szerkesztve ]

hello
szükségem lenne egy kis sql adatbázis link segítsége
belépek A adatbázisba ésle szeretnék futtatni egy tök egyszerű selectet ami B-re hivatkozik. tudnátok segíteni hogy kell ezt pontosan leírni

select * from tábla
create database link B connect to user identified by pw
using 'A'

eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei

create database link B connect to user identified by pw using 'A';
select * from tabla@B;

Nekem nem tudnál segíteni, kérlek?

Megírni senki nem fogja helyetted, kezd el, ha elakadsz és kérdésed van, akkor azt tedd fel.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Segítek: Sqlfiddle
Rajta!

Én kérek elnézést!

Sziasztok!

Van 3 táblám a következők

Versenyző: id, név, szám
Kategóriák: id, kategóri megnevezés
Nevezett: versenyzoid, kategóriid

Miképpen tudnám én a nevezettek nevét és kategóriáját megkapni egyetlen lekérdezésben.

Két lekérdezéssel sikerült megoldanom, de egyel kéne megcsinálnom. Inner join-al kapcsoltam össze a két táblát és a z eredmény kielégítő volt, csak nem tudom a 3. táblát hogyan lehetne hozzákapcsolni, hogy akkor is adjon eredményt.

Elárulok egy titkot: Akárhány join-od lehet egy lekérdezésen belül.

Én kérek elnézést!

Az oké, csak valahogy nem akarja úgy kiadni biztos valamit én rontok el.

Tehát ha összekapcsolom a nevezetteket a kategóriával akkor szépen ki tudom íratni a kategórianevét és látom a versenyző id-ját is, de ha ehhez a lekérdezéshez hozzáadok még egy join-t akkor már nem lesz eredménye a lekérdezésnek. (pedig van olyan id-jű versenyző)

Én is így gondoltam, mert itt lekérdezésem

SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
INNER JOIN Classes c ON r.ClassID = c.ID

Ugyan ezt írom le mégsem ad eredményt

Azért, mert r.RacerID = a.ID helyett a.RacerID = r.ID kell.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Légyszi tedd fel Sqlfiddle-re a minta táblákat, meg a megírt lekérdezésedet is, aztán megnézzük.

Én kérek elnézést!

Lehet, hogy nincs minden addresshez rating és class? Látatlanba próbáld meg left outer joinokkal...
Előre azt a táblát írd, amiből mindenféleképp szeretnéd az összes adatot, utána a többi táblát.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Elég fura egy szerzet sqlfiddle-n működik: [link]

Szétszedve a lekérdezést működik:

"SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
WHERE r.EventID = " + eventID + " "

"SELECT * FROM Rating r
INNER JOIN Classes c ON r.ClassID = c.ID
WHERE r.EventID = " + eventID + " "

Összerakva nem:

"SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
INNER JOIN Classes c ON r.ClassID = c.ID
WHERE r.EventID = " + eventID + " "

[ Szerkesztve ]

ilyenkor jön az, hogy hagyod a pokolba a szép, elegáns, meg minden joinokat, és megcsinálod a régi szintaxissal:

select versenyzo.nev, kategoriak.megnevezes from versenyzo,kategoriak,nevezett where
nevezett.versenyzoid=versenyzo.id and nevezett.kategoriaid=kategoriak.id;

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Hát igen ez lett úgy néz ki a megoldás, de akkor is zavar, hogy miért nem megy join-al

(#2029) fordfairlane: nem ír semmi hibát, amúgy ez egy visual studio-ban íródó program ami Microsoft Access adatbázisból dolgozik.

(#2031) martonx: Amúgy igen eltér egymástól mivel ebben már van egy csomó rekord (több 100), én örülnék a legjobban ha tiszta lenne és nem kénének a régi adatok.
De most simán bambano ajánlása szerint működik
Megpróbálom azért úgy is.

[ Szerkesztve ]

Nyilván eltér az sql fiddle-re felvitt adat, és az otthoni db-den lévő adat.
Az otthoniban valami szemét lehet. Próbáld ki az inner join-ok helyett left outer join-okkal.

Én kérek elnézést!

Üdv mindenkinek!

Feltettem már a kérdésemet több topicban is, aztán martonx fórumtárs javaslatára idetévedtem, és megkérdezlek benneteket is a dologról.

Adott a következő részlet egy EK diagramból, ezt szeretném átírni relációs adatbázisba:

Elméleti szinten megy a dolog, viszont az SQL-lel bajban vagyok. Ami "biztos", hogy 3 táblám lesz. A felhasználó és a termék marad ugyanúgy, de kell készítenem egy kapcsolótáblát, legyen mondjuk feltöltötte, ami megkapja a felhasználó és a termék tábla elsődleges kulcsát, és ez a kettő együtt lesz az idegen kulcsa, valamint megkapja a kapcsolat tulajdonságát is.

Innentől van a gond, mert nem tudom, hogy miként tudom helyesen feltölteni az adatbázist...

Például olyan lekérdezésekre szeretnék választ kapni, hogy Józsi milyen termékeket töltött fel?, vagy hogy a Danone joghurtot ki töltötte fel?.

A kapcsolótábla teljesen megzavar, ezt hogy kell létrehozni SQL-ben, és aztán feltölteni bele?

[ Szerkesztve ]

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

Én úgy csinálnám, hogy a meglévő adatok alapján felvinném az összes felhasználót a felhasználó táblába, az összes terméket pedig a termék táblába (mindenkit és mindegyiket csak egyszer).

Nem tudom, hogy hívják magát a "feltöltést", de hasonló esetben én a tranzakció kifejezéssel találkoztam. Tehát van egy halom tranzakciód, ami tartalmazza, hogy ki, mit és mikor töltött fel. Ezeket kell a kapcsolótáblába felvinni. (felhasználó egyedi azonosítója + termék egyedi azonosítója + feltöltés dátuma)

Innentől kezdve csak a kapcsolótáblát töltöd. Akkor kell a másik kettőhöz hozzányúlnod, ha új felhasználó vagy új termék jelenik meg egy tranzakcióban. (Ez esetben a felhasználó- és/vagy a terméktáblát kell előbb kiegészíteni.)

[ Szerkesztve ]

Húh, lehet, hogy nem értjük egymást, bár szerintem én is körülményesen magyaráztam.

Amit mondasz, az lehet, sőt biztos, hogy működne, de az a probléma, hogy esetemben kezdésnek 0 felhasználó és 0 termék van, szóval nem kivitelezhető, hogy előre felvigyem őket.

Gondolkoztam, és lehet, hogy így nem is logikus, mert mi a fenéért vinné fel több felhasználó is ugyanazt a terméket?! Tehát annyiban módosítani kell majd az ábrát, hogy egy felhasználó több terméket is felvihet, viszont egy adott terméket csak egy felhasználó vihet fel. De ebben az esetben az időpont sem kell, mert teljesen mindegy, mikor vitte fel, nincs jelentősége...

Szóval akkor egy-a-többhöz lesz, és innen már más a helyzet. Na, ezt még át kell gondolnom...

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

Nagyvonalakban ezek az infóid vannak:

felhasználó | felhasználói infók (több mező) | termék | termékinfók (több mező)

Azt írod, hogy nincs két ugyanolyan termék (-> különböző vonalkódok). Ha így van, akkor szerintem felesleges a kapcsolótábla. Az egész mehetne egy táblába. Annyit lehetne normalizálni rajta, hogy a felhasználóknak külön táblát hozol létre, amibe minden felhasználói infót letárolsz, a másik táblában pedig elég csak felhasználóazonosítót használnod.

Igen, lényegében a szabály alapján is így kell eljárnom, ha egy-a-többhöz kapcsolat lesz. De még lerajzolom párszor, meg átgondolom, aztán majd jelentkezem, hogy mire jutottam.

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

Sziasztok, egy kis segítséget szeretnék kérni. Van az alábbi lekérdezésem. És a kiemelt right join-t vmi inner joinra kényszeríti és nem tudok rájönni mi.
a bal lekérdezés kb 70k rekordot dob, a jobb oldali kb 4k-t. A végeredményemben 4k körül kéne lennie, de csak 1,5k lesz. Sejtésem szerint az aláhúzott részt szól bele, de nem tudom mi kéne kezdeni vele.
Ha esetleg vkinek beugrik erre vmi azt megköszönném.

DECLARE @date date
set @date='2013.06.30'

SELECT r.[pkod]
,r.[fhely]
,cast (sum(r.[me]) as int) as me
FROM [crm_szamla] as r
[B] right join[/B]

(SELECT c.kod
,c.pkod
,c.szlakor
,a.[gyszam]
,[beszerel]
,[leszerel]
,b.utolsó_leolv
,b.utolsó_allas
FROM [crm_meroora] as a

inner join
(SELECT id_fhely
,[gyszam]
,max(kelte)as utolsó_leolv
,max(allas) as utolsó_allas
FROM [crm_leolv] where kelte<=@date
group by id_fhely, gyszam having max(kelte)<@date) as b
on a.id_fhely=b.id_fhely and a.gyszam=b.gyszam and utolsó_leolv<@date and beszerel<@date and (leszerel>@date or leszerel is null)
left join
crm_fhely as c on a.id_fhely=c.id and left(kod,3)<>312 and left(kod,3)<>317 and c.megszunt is null ) as c
on r.fhely=c.kod and r.pkod=c.pkod and tipus='VF' [U]and idoszak_i<=@date and r.idoszak_t>=c.utolsó_leolv [/U]
group by r.fhely, r.pkod
order by fhely

[ Szerkesztve ]

Nekem kicsit fura ez a lekérdezés. Pl. nem értem, hogy a tipus='VF' előtt miért nem szerepel a WHERE záradék. Talán ez a szűrés lehetne a másfélezer sor egyik oka. A másik pedig a GROUP BY a végén...

Az egyébként r.tipus lenne, azért nincs előtte where mert az is kényszerítené az inner joint. A right helyett left joinnal próbálom, akkor az jól működik, de csak akkor ha nincs ott a where.
A jelenlegi formájában ha beszúrom a where-t akkor nincs különbség az eredményben.

A groub by pedig muszáj a végére, mert a sub-ból jön eredmény ami befolyásolja a left táblát.

Ha LEFT JOIN-nal helyes eredmény jön ki, akkor a probléma a "c" allekérdezésben van, ami kb. így néz ki:

crm_meroora INNER JOIN crm_leolv LEFT JOIN crm_fhely

Nem lehet, hogy az ebben lévő INNER JOIN szűkíti feleslegesen az allekérdezést?

Úgy értettem, hogy a left join működik rendesen, a right join pedig inner joinként viselkedik. Sajnos a left join nem a keresett eredményt adja vissza.

Az allekérdezés magában tökéletesen működik. A "bal oldali" lekérdezés is jól működik, csak ha jön a join akkor megy vmi félre.

Hasonló problémára gyanakodtam, mint a linken szereplő, de ha ennek megfelelően írom át, akkor se jó.

Akkor én passzolom. Esetleg feltehetnél egy példaadatbázist SqlFiddle-re, ha más nem tud rá megoldást. (Nekem ez a JOIN-os módszer eléggé idegen, átírnám a régi kódra.)

sqlfiddle példa nélkül mégis mit vársz tőlünk?

Én kérek elnézést!

Sziasztok,

valami leírás, tutorial félét keresnék ,belefuttottam egy (nekem) új témába, és nem nagyon boldogulok vele. Egy táblában faszerkezet, ebben kellene nekem számolni. A legalsó szint darabszámát kéne felszorozni az osszes szülője darabszámával.

Tud esetleg valaki valami jó leírást, ahonnan ezt a részt megérthetném?

MZ/X

Ez erősen attól függ, hogy van a faszerkezet lekezelve adatbázis szinten...

És még...

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Szia,

köszi, elkezdek ismerkedni, közben sikerült megcsinálni amit akartam, de a produktumra nem vagyok büszke... valószínűleg ha kéne, már most nem tudnék belejavítani

parent_id -- child_id kb így van, és ugye a gyerek is lehet szülő.

MZ/X

Üdv mindenkinek!

Arra kérnélek benneteket, hogy illusztráljátok konkrét példával, vagy csak simán konyhanyelven, hogy a több-a-többhöz kapcsolat esetén mi szükség van a kapcsolótáblára? Az addig rendben van, hogy bele kerül mindkét elsődleges kulcs, de ebben mi a pláne?

Leírom a saját példámat, kérlek véleményezzétek, jól értem-e a dolgot. Az egyik egyed legyen "termék", a másik pedig "áruház". Egy áruházban megtalálható több termék is, és egy termék több áruházban is megtalálható.
Tehát készítek például egy "megtalálható" nevű kapcsolótáblát, ebbe kerül 2 elsődleges kulcs, ami mutatni fog a "termék" és az "áruház" tábla elsődleges kulcsaira. Ebből azt tudom majd megmondani, hogy egy adott termék mely áruházakban van, illetve fordítva, vagyis hogy egy adott áruházban milyen termékek vannak? Tehát ennyi lenne a kapcsolótábla szerepe?

A másik, ami még érdekelne, hogy SQL szinten ezeket hogy lehet bepötyögni, hogy megértse az adatbázis-kezelő rendszer? Olvastam REFERENCES kulcsszót is, meg valami CASCADE-t is, de utóbbit nem igazán tudtam értelmezni, hogy mire jó.

Aztán van még jópár problémám, például hogy miként töltöm fel a kapcsolótáblát? Sima INSERT, ahogy egy "átlagos" táblába szúrnék be, vagy van valami speciális kapcsolója?

Az a problémám, hogy a neten fellelhető doksik többnyire angol nyelven vannak, és hiába értem meg magát az angolt, ha ott olyan szavakkal dobálóznak, amit amúgy magyarul sem értek...

Köszi a válaszokat előre is!

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

Ebből azt tudom majd megmondani, hogy egy adott termék mely áruházakban van, illetve fordítva, vagyis hogy egy adott áruházban milyen termékek vannak? Tehát ennyi lenne a kapcsolótábla szerepe?

Igen, mivel egy rekord egy mezője csak egy elemet tartalmazhat (logikailag), így a
[tábla 1] n:m [tábla 2]
kapcsolatot fel kell bontanod:
[tábla 1] 1:m [kapcsoló tábla] n:1 [tábla 2]
formára.

[link]

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Köszönöm, akkor legalább ezt már értem.

Oké, a kapcsolótáblán keresztül felbontom a több-a-többhöz kapcsolatot. Lekérdezésnél mindenképp JOIN kell, ha például azt akarom megtudni, hogy egy adott áruházban milyen termékeket vásárolhatok meg?
Mert - érzésem szerint - valahogy mindenképp bele kell venni a kapcsolótáblát is a lekérdezésbe, de hogy hogyan, az egyelőre nekem rejtély.

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

ahhoz, hogy lásd ennek a célját, érdemes először alaposan elolvasni a Chomsky-féle normálformákat.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis