Új hozzászólás Aktív témák
-
#2925
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Kifejezetten magyar lakcímek összehasonlítására tudna valaki kódot vagy kódkezdeményt adni?
Ez egész jó, de nem tudom, hogy szükséges-e adattisztítás pl. az ékezetek miatt. -
#2827
Apollo17hu
őstag
beni26k
#2826
Apollo17hu
őstag
válasz
beni26k
#2826
üzenetére
Csak egy nagyon távoli tipp, hátha valakinek beugrik, mi okozza a problémát:
Nem lehet, hogy az alkalmazások eltérő tizedesjelölőt használnak, és ami az egyikben szám, azt a másik csak szövegként tudja értelmezni? (Munkahelyen volt ilyen gondom, ott a Windows területi beállításai tértek el az adatbáziskezelő nls-paramétereitől.) -
#2811
Apollo17hu
őstag
-=Flatline=-
#2810
Apollo17hu
őstag
válasz
-=Flatline=-
#2810
üzenetére
MySQL-t nem vágom, Oracle-ben a rank() függvénnyel lehetne megoldani valahogy így:
select rank() over (partition by t.kvizid, t.name, trunc(t.time) order by t.time) as sorrend
Ez egy olyan oszlopot generálna neked, ahol kvízenként, azon belül userenként, azon belül naponta minden egyes választ sorba rendez időpont alapján. Erre az oszlopra szűrve - ha előtte rászűrtél, hogy a teljes listából csak a helyes válaszokra van szükséged - elég csak az '1' értékeket megtartani, mivel ezek lesznek adott kvízhez adott napon adott user első helyes válaszai.
Tehát a dolgod, hogy keress valami sorrendfüggvényt MySQL-ben...
-
#2808
Apollo17hu
őstag
gerg0
#2807
Apollo17hu
őstag
Valamivel kötnöd kellene a 3 lekérdezést (--> táblát).
Nekem elsőre az az ötletem, hogy vedd azt a lekérdezést, ahol COUNT(*) értéke a legnagyobb, egészítsd ki egy sorszám oszloppal - akár rank() analitikus függvénnyel, de talán a rownum is alkalmas rá -, majd a másik két lekérdezést - szintén sorszám oszloppal kiegészítve - kösd az előbbihez gyengén.
-
#2761
Apollo17hu
őstag
dellfanboy
#2759
Apollo17hu
őstag
válasz
dellfanboy
#2759
üzenetére
Nem biztos, hogy hibás. Attól függ, mi a kérdés, amire a scriptet írod.
-
#2624
Apollo17hu
őstag
Apollo17hu
#2623
Apollo17hu
őstag
válasz
Apollo17hu
#2623
üzenetére
Mondjuk ez SQLite, de megerősíti, amit írtam:
"The WITH clause cannot be prepended to the second or subsequent SELECT statement of a compound select." -
#2623
Apollo17hu
őstag
Kommy
#2620
Apollo17hu
őstag
Akitől kaptad, annál működik?
Nekem nagyon kuszának tűnik az egész, bár én eleve nem JOIN-okat használok.
Egy tippem van: elképzelhető, hogy virtuális nézeten (WITH) belül nem lehet virtuális nézetet létrehozni. Sőt, nem is értem, hogy miért van rá szükség, ha a belső virtuális nézetre egy SELECT * FROM kerül...
-
#2564
Apollo17hu
őstag
dellfanboy
#2560
Apollo17hu
őstag
válasz
dellfanboy
#2560
üzenetére
Nem JOIN-nal szoktam kötni, de - ha jól tudom -, akkor a FROM utáni sorrend dönti el, hogy melyik a "LEFT" és melyik a "RIGHT" tábla. A LEFT JOIN és a RIGHT JOIN is "gyenge" kötés, tehát az egyik táblának vesszük az összes rekordját, és amihez párt találunk, ahhoz hozzácsapjuk a másik táblából a szükséges mezőket, ahol pedig nincs pár, az NULL-értékkel kerül feltöltésre.
Ebből következik, hogyha neked csak azok az id-k kellenek, amelyek kizárólag az egyik táblában vannak, akkor a másik táblát gyengén kell kötnöd hozzá, majd a WHERE záradékban meg kell adnod, hogy a másik táblából bekötött id-k helyett NULL-érték szerepeljen. Valahogy így:
SELECT egyik_tabla.id
FROM egyik_tabla
LEFT JOIN masik_tabla
ON egyik_tabla.id = masik_tabla.id
WHERE masik_tabla.id IS NULLMegj.: gugliba beírod, hogy sql join, és rámész a képkeresőre, meg fogsz világosodni.
-
#2524
Apollo17hu
őstag
joni1700
#2523
Apollo17hu
őstag
válasz
joni1700
#2523
üzenetére
Szia!
Normál SQL-ben úgy csinálnám, hogy létrehoznék két extra oszlopot az árnak: MIN(Ár) és MAX(Ár). Ezeket pedig összefűzném valahogy így:
SELECT [Név]
,[Feltét]
,MIN([Ár]) || ' - ' || MAX([Ár]) AS intervallum
FROM [Tábla]
GROUP BY [Név]
,[Feltét](Nem tudom leellenőrizni, előfordulhat, hogy hibás a szintaktika.)
-
#2509
Apollo17hu
őstag
dellfanboy
#2507
Apollo17hu
őstag
válasz
dellfanboy
#2507
üzenetére
Úgy kell csinálnod, ahogy Athlon64+ írta: betöltöd mondjuk egy "ugyfel" nevű táblába, és egyszerűen összekötöd (erősen) azzal a táblával, amiben az azonosítókat szűrni szeretnéd.
Valahogy így:
SELECT alaptabla.*
FROM alaptabla, ugyfel
WHERE alaptabla.id = ugyfel.idEz semmi mást nem csinál, mint az alaptáblából leszűri azokat a rekordokat, amelyek - azonosító alapján - szerepelnek az ugyfel táblában is.
-
#2471
Apollo17hu
őstag
Agony
#2470
Apollo17hu
őstag
Erre egy komplett logikát kellene építeni.
Mi van akkor, ha ketten is 4 lóval indulnak? Akkor a másik a 2., a 11., a 21. és a hányadik(?) induló legyen a sorban? És mi legyen azokkal, akik 3 lóval indulnak? Mi van, ha valaki 8 lóval indul? Hogy kezelje le a közös többszörös eseteit? (2 lovasok vs. 4 lovasok vs. 8 lovasok vagy akár a 6 lovasok is ide kerülhetnek)
Analitikus függvények mentén kellene elindulnod...
-
#2425
Apollo17hu
őstag
Agony
#2424
Apollo17hu
őstag
dátumokat másodpercekig lebontva
to_date(dátummező, 'yyyymmdd')
vagy
trunc(dátummező)(valamelyik csak működik
)összegeket meg több mint 5 tizedesjegyig
trunc(összeg)
vagy
round(összeg,2)
vagy
floor(összeg) -
#2423
Apollo17hu
őstag
Agony
#2422
Apollo17hu
őstag
Ezeket a convert() meg cast() függvényeket mondták neked vagy magadtól használod? Nagyon ritkán találkozom velük, de szerintem nem is biztos, hogy szükség van rájuk.
A nullával osztást én úgy szoktam áthidalni, hogy elágazást írok rá:
CASE
WHEN nvl(t.EGYSAR, 0) = 0 THEN
NULL -- vagy amit szeretnél helyette
ELSE
convert(varchar(20),cast((t.KEDV/t.EGYSAR)*100 as decimal(15,2)))
END as 'Kedvezmény (%)' -
#2420
Apollo17hu
őstag
Agony
#2419
Apollo17hu
őstag
Szia!
Ránézésre szerintem addig oké, hogy gyengén (LEFT JOIN) kötöd a {k} és a {g} táblát, de utána {k} -hoz is és {g} -hez is erősen (INNER JOIN) kötöd {i}-t és {j} -t. Ha elhagynád az {i} és a {j} tábla bekötését (vagy ha LEFT JOIN-nal kötnéd azokat is), akkor valószínűleg stimmelne a rekordszámod.
Egyébként a végén a dátumszűrést egyszerűbb úgy csinálni, hogy BETWEEN [kezdődátum] AND [végdátum].
-
#2418
Apollo17hu
őstag
DopeBob
#2417
Apollo17hu
őstag
válasz
DopeBob
#2417
üzenetére
Nem értem, ha feltételben kell használnod, akkor nem tudod megspórolni.
A &változó maga egyfajta tárolás, amikor beszúrod, egy hivatkozás kerül a kódba (nem tudom, helyes-e a megfogalmazás).
Én nem látom, hol lehetne rövidíteni a kódon (hacsaknem a szűrőfeltételeket fogalmazod át más logika mentén).
-
#2399
Apollo17hu
őstag
Agostino
#2398
Apollo17hu
őstag
válasz
Agostino
#2398
üzenetére
Miért akarod összefésülni?
Azért nem tudod megcsinálni, mert januárban két teljesen azonos rekordod van (1, alma, kamra), tehát nincs egyedi kulcs hozzájuk. Neked kellene valamilyen szempont (mező) alapján megmondani, hogy a két rekord közül melyikhez kösse hozzá februárt, de nincs ilyen mező.Úgy nem jó, hogy UNION ALL-ozod a két táblát, és kiegészíted a létrejött táblát egy hónap oszloppal?
SELECT 'január' AS hónap, id, gyümi, hely
FROM január
UNION ALL
SELECT 'február' AS hónap, id, gyümi, hely
FROM február(Ékezeteket természtesen nem kellene, de talán érthető, hogy gondoltam.)
szerk.: Amúgy biztosan jó a januári táblád, hogy duplikálva van egy rekord?
-
#2395
Apollo17hu
őstag
dellfanboy
#2394
Apollo17hu
őstag
válasz
dellfanboy
#2394
üzenetére
Amit 2 hsz.-szel korábban írtál, az a 3 tábla metszete. A metszetben lehet szűrni id-ra (= Melyek azok az id-k, amelyek mindhárom táblában megtalálhatóak?), ekkor mindegy, hogy a háromból melyik tábla id-jára szűrsz. Ha több id-ra akarsz szűrni, akkor az IN operátort használd!
megszámolom az oszlopban lévő értékeket de csak akkor ha az id x.
Ezt nem értem. Lehet, hogy az id mellett vannak más mezőid, amiket összegezni szeretnél? Ha így van, akkor lehet, hogy a SUM()-ra is szükséged van.
-
#2374
Apollo17hu
őstag
dellfanboy
#2373
Apollo17hu
őstag
válasz
dellfanboy
#2373
üzenetére
Így nehéz segíteni, még mindig nem jött át, hogy pontosan mi a problémád.
Az a gondod, hogy 1000+ soros a lekérdezésed? Mert valami olyasmit csinálsz, hogy WHERE id = 564 or id = 5688 or id = 5212 or id = 213 ...?És az az x db vevő honnan van neked? Hogy szűrted le? Vagy kaptad valahonnan egy Excel-fájlban?
-
#2372
Apollo17hu
őstag
dellfanboy
#2370
Apollo17hu
őstag
válasz
dellfanboy
#2370
üzenetére
Ez nekem nem jött át. Hogy néz ki a lekérdezésed? LIKE / BETWEEN operátorokat ismered?
-
#2371
Apollo17hu
őstag
dellfanboy
#2369
Apollo17hu
őstag
válasz
dellfanboy
#2369
üzenetére
írok egy selectet megvan az eredmény a plsql behoz kb 20 sort. ekkor szoktam a zöld le nyílra kattintani (ugrás az utolsó oldalra), hogy lehozza a maradékot (és itt néha megakad a 100mb miatt)
Egyrészt be lehet állítani a Developert, hogy ha lefut a lekérdezés, akkor az eredményt automatikusan pörgesse ki (nem ajánlott), másrészt ha 100 MB-nál megakad a kipörgetés, utána ha nyomsz mégegyet a zöld nyílra, akkor kipörgeti a maradékot is, és mehet az export.
A query eredmény exportálása funkciót nem használtam még.
-
#2368
Apollo17hu
őstag
dellfanboy
#2366
Apollo17hu
őstag
válasz
dellfanboy
#2366
üzenetére
A meghaladja a 100 MB-ot nem arra vonatkozik véletlenül, hogy nem pörgette ki (fetch) az összes eredménysort? Ilyet szokott nálam is pampogni, de ha teljesen kipörgetem, akkor engedi az exportot. És nem 100 megás Excel-fájlod lesz, hanem töredéke.
Egyébként akkor kapsz ilyen 100 megás üzit, ha a sok rekord baromi sok mezőből áll. Ha csak a legfontosabb mezőket hagyod a lekérdezésedben, akkor sztem még az üzenet sem fog megjelenni.
-
#2363
Apollo17hu
őstag
dellfanboy
#2361
Apollo17hu
őstag
válasz
dellfanboy
#2361
üzenetére
Mi nem megy az exportálásban? Ha sok az adat, akkor kicsit "gondolkodni" szokott a Developer, de nekem mindig kirakja, amit ki kell. Ha meg már Excel-ben van, akkor xlsb-ként mentsd el, és akkor kb. akkora lesz a fájlod mérete, mintha zippelted volna.
-
#2350
Apollo17hu
őstag
FireFox1996
#2349
Apollo17hu
őstag
válasz
FireFox1996
#2349
üzenetére
nem kötekedés akart lenni, nem tanultam a dolgot ilyen mélységben
kösz a választ -
#2348
Apollo17hu
őstag
FireFox1996
#2347
Apollo17hu
őstag
válasz
FireFox1996
#2347
üzenetére
Ha már ilyen mértékű optimalizálásról esett szó, azt nem tudod véletlenül, hogy a kommentezések (nem a hintek, hanem a normál kommentek) lassítanak-e bármit a futási időn?
-
#2343
Apollo17hu
őstag
sztanozs
#2341
Apollo17hu
őstag
válasz
sztanozs
#2341
üzenetére
Nem kell bele.
Automatikus szövegkiegészítést és programkód-rendezőt (beautifier) használok: [w] + [space] lenyomására a "WHERE 1 = 1 AND" karaktersorozatot kapom. Az "1 = 1" miatt a beautifier a következő sorba rendezi az AND operátort és az azt követő feltételt, így ha ki kell kommenteznem, nem kell azzal bajlódnom, hogy a WHERE -rel egy sorban van, így az egész sort kommentezhetem duplakötőjellel.
-
#2340
Apollo17hu
őstag
Roley_05
#2339
Apollo17hu
őstag
válasz
Roley_05
#2339
üzenetére
Analitikus függvényekkel (LAG, LEAD) lehetne megoldani, de szerintem neked egyszerűbb, ha fogod a táblád, és hónap mentén visszakötöd önmagába.
Feltételezve, hogy számként tárolod a hónapot, ezt talán le tudod futtatni:
SELECT t1.honap
,t1.ertek
,t2.ertek AS korabbi_ertek
FROM tabla AS t1
,tabla AS t2
WHERE 1 = 1
AND t1.honap = t2.honap(+) + 1 -
#2313
Apollo17hu
őstag
nova001
#2310
Apollo17hu
őstag
válasz
nova001
#2310
üzenetére
Ne INNER JOIN-t használj, mert az a [szoba] és a [foglalt] táblák metszetét adja, tehát pont hogy a foglalt szobák listáját kapod. Neked olyan szobák kellenek, amelyek (1) vagy nincsenek benne egyáltalán a [foglalt] táblában, (2) vagy benne vannak, de nem a kiválasztott két éjszakára lefoglalva.
Kezdésnek LEFT JOIN-nal kösd a [foglalt] táblát, ezután pedig a kapott listát szűrd le (1) és (2) szerint.
-
#2214
Apollo17hu
őstag
Apollo17hu
őstag
Az nvl-es megoldás működik, ezt kerestem. Ha esetleg lehet még javítani a kódon, azt szívesen fogadom.
-
#2211
Apollo17hu
őstag
FireFox1996
#2210
Apollo17hu
őstag
válasz
FireFox1996
#2210
üzenetére
Ez már így szerintem nem a "legegyszerűbb" megoldás.
Maradok egyelőre Zeratul javaslatánál, remélhetőleg alkalmazható. -
#2209
Apollo17hu
őstag
FireFox1996
#2208
Apollo17hu
őstag
válasz
FireFox1996
#2208
üzenetére
Nem, az azonosító és az időbélyeg együttesen kulcs.
t1:
id calendar_date
1 2013.12.31
2 2014.01.01
3 2013.12.31
4 2014.01.01
6 2013.12.31
8 2013.12.31
9 2013.12.31
12 2013.12.31t2:
id calendar_date
1 2013.12.31
3 2013.12.31
5 2013.12.31
6 2013.12.31
8 2013.12.31
11 2014.01.01
15 2014.01.01ezt szeretném:
id t1_fl t2_fl
1 x x
3 x x
5 x
6 x x
8 x x
9 x
12 x -
#2205
Apollo17hu
őstag
FireFox1996
#2204
Apollo17hu
őstag
válasz
FireFox1996
#2204
üzenetére
Ez azért nem lenne jó, mert ha mindkét táblában megvan a rekord, akkor csak az egyikre vonatkozó érték (1 vagy 2) fog megjelenni "honnan"-ban.
-
#2203
Apollo17hu
őstag
FireFox1996
#2201
Apollo17hu
őstag
válasz
FireFox1996
#2201
üzenetére
A legegyszerűbb megoldást keresem egy olyan halmaz létrehozására, ami tartalmazza t1 és t2 minden elemét (az azonos elemeket csak egyszer), és segédmezőkben tárolom, hogy az elem megtalálható-e t1-ben és/vagy t2-ben. Utóbbira CASE WHEN t1.id IS NOT NULL THEN 'x' END t1_fl és t2_fl mezőket vettem fel. Nem tudom, hogy UNION ALL -lal a segédmezők megvalósíthatóak-e. (A segédmezőkre később szűrök, ezért kellenek.)
-
#2199
Apollo17hu
őstag
Apollo17hu
őstag
FULL OUTER JOIN-nal azonosítón keresztül összekötök két táblát. A táblákban időbélyegek vannak, mindkettőben adott nap (ugyanaz a nap) érdekel csak. Ha a táblákat allekérdezésbe rakom, és "előszűröm" őket a szükséges napra, akkor működik a lekérdezésem.
Van allekérdezés nélküli megoldás? Ez a kód nem jó, mert a WHERE miatt metszetet kapok unió helyett (-> "megöli a FULL OUTER JOIN-t")
SELECT ...
FROM t1
FULL OUTER JOIN
t2
ON t1.id = t2.id
WHERE 1 = 1
AND t1.calendar_date = to_date('20131231', 'yyyymmdd')
AND t2.calendar_date = to_date('20131231', 'yyyymmdd') -
#2166
Apollo17hu
őstag
csabyka666
#2165
Apollo17hu
őstag
válasz
csabyka666
#2165
üzenetére
A 4 mezőben keresel azt jelenti, hogy a felhasználó max. 4 szót adhat meg szűkítésnek? Szerintem a keresők nem ezen az elven működnek, de ha te így szeretnéd, akkor talán az AND mégis használható lenne, ha REGEXP helyett LIKE '%keresés%' jellegű kifejezéseket vizsgálnál. Amúgy a REGEXP honnan jött? Miben jobb a LIKE-nál a lekérdezésedben?
-
#2125
Apollo17hu
őstag
csabyka666
#2124
Apollo17hu
őstag
válasz
csabyka666
#2124
üzenetére
SELECT * FROM tabla
WHERE UPPER(mezo) LIKE '%ALMA%' -
#2040
Apollo17hu
őstag
drogery
#2039
-
#2035
Apollo17hu
őstag
csabyka666
#2034
Apollo17hu
őstag
válasz
csabyka666
#2034
üzenetére
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.
-
#2033
Apollo17hu
őstag
csabyka666
#2032
Apollo17hu
őstag
válasz
csabyka666
#2032
üzenetére
É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.)
-
#2006
Apollo17hu
őstag
Tv
#1998
Apollo17hu
őstag
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.
-
#1912
Apollo17hu
őstag
dellfanboy
#1911
Apollo17hu
őstag
válasz
dellfanboy
#1911
üzenetére
Nekem is volt szerencsém mindkettőhöz.
Az SQL Developer-t egyetemen fél évig használtuk. Arra jó volt, hogy fogalmat kapjunk a relációs adatbázisokról, a többfelhasználós környezetről, és alap SQL utasításokat is írtunk. Sajnos nem tudom, ennél mennyivel tudhat többet a program, de azt külön hangsúlyozta a szemináriumvezetőnk, hogy azért az SQL Developerre esett a tanszék választása, mert teljesen ingyenes.
Munkám során pedig PL/SQL Developert használok, és bár a "PL" funkcionalitást szinte egyáltalán nem használom ki, sokkal profibbnak tűnik, bővebb funkcionalitással (pl. automatikus kódkiegészítések). (Ez lehet, hogy azért is van, mert 3 év alatt volt időm megismerkedni vele.) Ő ugye fizetős...
-
#1885
Apollo17hu
őstag
Speeedfire
#1884
Apollo17hu
őstag
válasz
Speeedfire
#1884
üzenetére
Jövő héten ki fogom próbálni, pont az volt a gáz, hogy a listagg() függvény nem engedte a DISTINCT-et.
-
#1883
Apollo17hu
őstag
Speeedfire
#1882
Apollo17hu
őstag
válasz
Speeedfire
#1882
üzenetére
Ja, most már értem. Akkor én passzolom a témát.
Botlottam már hasonló problémába korábban, akkor úgy szerettem volna az értékeket összefűzni egy mezőbe, hogy az ismétlődések csak egyszer jelenjenek meg benne. Lényegében te is ezt csinálnád a nullértékekkel/nullákkal. Na, erre nincs normális függvény [prog.hu -n legalábbis nem tudtak segíteni, és gugli is csak olyan találatokat adott, ahol ciklusokat kell használni (PL/SQL)].Esetleg ha úgy csinálnád, hogy:
SELECT
CASE WHEN a.int1 IS NOT NULL THEN a.int1 || ', ' END ||
CASE WHEN a.int2 IS NOT NULL THEN a.int2 || ', ' END ||
CASE WHEN a.int3 IS NOT NULL THEN a.int3 || ', ' END ||
CASE WHEN a.int4 IS NOT NULL THEN a.int4 || ', ' END ||
CASE WHEN a.int5 IS NOT NULL THEN a.int5 || ', ' END ||
a.int6
FROM (...) a -
#1881
Apollo17hu
őstag
Speeedfire
#1880
Apollo17hu
őstag
válasz
Speeedfire
#1880
üzenetére
Az nem lenne jó, ha előbb a 2. táblából csinálnál egyetlen konkatenált oszlopot (+ mellé az id oszlopot), majd az így kapott lekérdezést kötnéd (allekérdezésként) az 1. táblához?
SELECT ...
FROM tabla1
JOIN (SELECT tabla2.id, [konkatenált oszlopok]
FROM tabla2)
ON tabla1.id = tabla2.id -
#1819
Apollo17hu
őstag
Speeedfire
#1818
Apollo17hu
őstag
válasz
Speeedfire
#1818
üzenetére
Igen, ugyanazt az eredményt hozza a kettő, de azért írtam be, mert a pivotot talán nehezebb "testreszabni" nagyobb mátrixoknál.
-
#1817
Apollo17hu
őstag
Speeedfire
#1811
Apollo17hu
őstag
válasz
Speeedfire
#1811
üzenetére
vagy:
SELECT id
,MIN(CASE
WHEN lang = 'hu' THEN
mess
END) AS "hu"
,MIN(CASE
WHEN lang = 'en' THEN
mess
END) AS "en"
FROM tabla
GROUP BY id -
#1805
Apollo17hu
őstag
Speeedfire
#1804
Apollo17hu
őstag
válasz
Speeedfire
#1804
üzenetére
Úgy akarod, hogy a lekérdezésed eredménye az legyen, hogy:
minden fórumazonosító (id) egyszer, ezekhez pedig a legutolsó (=legfrissebb) komment (comment), és a hozzá tartozó create_time érték? Ha igen, akkor kell bele a comment mező is vagy elég csak az időpecsét? -
#1720
Apollo17hu
őstag
nyunyu
#1717
Apollo17hu
őstag
Ilyet én is szoktam csinálni. Az a feladat, hogy megadott feltételek szerint válogassam ki a szükséges néhánytízezer rekordot egy segédtáblába, amivel később a hónap folyamán dolgozunk. A rekordokat könnyű kiválasztani, de kb. 100 attribútum tartozik hozzájuk, azokat pedig 20-25 adattáblából kell összeszedni. Ha ezeket mind egyetlen lekérdezésbe írnám, az életben nem futna le. (Optimalizáláshoz nem értek, az IT-segítség pedig sok lóvéba kerül.
) Ezért a leválogatott rekordokhoz később, UPDATE-ekkel keresem ki az attribútumokat - akár egyesével az eddig fel nem használt adattáblákból. -
#1716
Apollo17hu
őstag
Ispy
#1715
Apollo17hu
őstag
Munkahelyemen mi is így írjuk a kötéseket. Ha jól tudom, azért van így, mert annak, aki nulláról kezdi az SQL-t, egyszerűbb a (+) operátor használatát megérteni (=könnyebben beletanul), mint a többféle JOIN-t, és könnyebb is olvasni a többszáz-/többezersoros kódokat. Nekem ráállt erre az agyam, és nagyságrenddel rövidebb idő alatt értelmezek egy ilyen kódot, mint ami JOIN-okkal van tele.
-
#1588
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Erre a régi meg új szintaktikára tudnátok egy-egy nagyon rövid példát írni? Miben jobb az új és miért? Van előnye a régi használatának? Köszi!
-
#1492
Apollo17hu
őstag
Inv1sus
#1490
Apollo17hu
őstag
válasz
Inv1sus
#1490
üzenetére
A discounts táblában fel kéne venned mégegy mezőt, ami a kedvezmény típusát jelölné (százalékos, konkrét érték stb.), így a discounts.discount értékét nem kellene figyelned. A CASE WHEN utasításban pedig a kedvezmény típusát jelölő mező értékét vizsgálnád. (Ez alapján lenne szorzás/osztás vagy összeadás/kivonás vagy egyéb művelet.)
-
#1441
Apollo17hu
őstag
csabyka666
#1440
Apollo17hu
őstag
válasz
csabyka666
#1440
üzenetére
főiskolai beadandó? hajrá!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#1377
Apollo17hu
őstag
martonx
#1376
Apollo17hu
őstag
válasz
martonx
#1376
üzenetére
Nincs meg az elméletem hozzá, csak lekérdezéseket írogattunk, arról szinte semmit nem tudok, hogy mi a teendő a MySQL szerver telepítésekor, és hogy mire kell figyelni, milyen kapcsolatokat kell beállítani telepítéskor stb. Erről is szükségem lenne egy emészthető leírásra, ha akad.
-
#1375
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Egyetemen az ingyenes SQL Developert használtuk adatbázis-kezeléshez. Szeretnék itthon is kisebb adatbázisokat létrehozni, a Developer segítségével pedig SQL-kódok formájában lekérdezéseket írni.
Mi szükséges ahhoz, hogy a PC-men mindezt meg tudjam valósítani (ingyen)? Van-e esetleg egyszerűbb/kezelhetőbb megoldás az otthoni adatbázis-kezelésre?
A hangsúly az SQL-lekérdezéseken van, nem kedvelem az Access-szerű varázslást...
-
#989
Apollo17hu
őstag
Alexios
#986
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Távol-keleti webshopok OFF topikja (játékok, kuponok, stb.)
- War Thunder - MMO Combat Game
- Borderlands 4
- Formula-1
- PlayStation 5
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Gyúrósok ide!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Okos Otthon / Smart Home
- Gumi és felni topik
- További aktív témák...
- Supra LoRad 2.5 Silver Anniversary edition 1,5 m
- HP EliteBook 840 G7 i5-10310U - TOUCH 16GB RAM 256GB NVMe világítós billentyűzet, üzleti laptop
- Philips 34" 34M2C3500L/00 WQHD VA 180Hz HDMI/DP ívelt gamer monitor (019)
- SAMSUNG S27FM502 Smart M5 IPS monitor (037)
- iiyama ProLite XB3270QS-B5 32"-os 2K IPS Pivot mode
- Eladó Dell Latitude 7440 Új állapotban i7-1365U 32 GB DDR5 RAM 1TB SSD Dell pro support garancia
- BESZÁMÍTÁS! LENOVO Legion 5 Pro 16ACH6H notebook - R7 5800H 16GB DDR4 512GB SSD RTX 3070 8GB
- BESZÁMÍTÁS! Asus B150M i5 7400 8GB DDR4 128GB SSD 1TB HDD GTX 1060 3GB Zalman T3 Plus DeepCool 400W
- ÚRIS10!!! RAMÁRON! LEGION 5 i7-13650HX 16GB RAM 512GB SSD RTX 5070 8GB 2K OLED 165Hz 500NIT
- Lenovo T14s Gen 1 Ryzen 7 pro 4750U, 16GB RAM, 512GB SSD, jó akku, számla, garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest