Új hozzászólás Aktív témák
-
nyunyu
félisten
Összejoinolod a 3 táblát, majd a wherebe írod a gépnév feltételt.
select g.gepnev, t.*
from gep g
join gep_tartozek gt
on gt.gep_id = g.id
join tartozek t
on t.id = gt.tartozek_id
where upper(g.gepnev) = 'KALAPÁCS';Régi szintaxissal nem írom le, tessenek a szabványt használni.
-
DS39
nagyúr
jó az irány.
még group by-old a külső select-et névre és telefonszámra, és az id-t MIN()-eld.
ezt mentsd el egy temp táblába, majd a temp táblához join-old be a partner táblát, név és telefonszám alapján + temp.ID <> partner.ID
így meglesz egy rekordban a duplikált partner régi és új id-ja, ezzel már könnyen meg tudod írni az update-t, hogy a kölcsönzés táblában mit mire kell cserélni.
+ én még a partner táblát bővíteném egy oszloppal, hogy törölt / archív, és a régi id-ek megjelölném, így később ki lehet őket szűrni. -
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...
-
bpx
őstag
pont az amit ir a hiba
csak classid szerint megy a group by, ilyenkor a tobbi oszlopra "osszesito" fuggveny kell, pl. COUNT, MAX, vagy azokra is group by-olni kell
az a baj a lekerdezessel, hogy mivel a classification oszlopra egyik sincs, igy annak erteke nem determinisztikus
mysql sajnos megenged ilyen lekerdezest, mas adatbaziskezelok szerencsere nem -
bambano
titán
-
fordfairlane
veterán
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ő)
Pedig sok variáció ezzel nincs, mivel egyértelmű, kit mivel kell összekapcsolni. Versenyzőket a nevezésekkel, azt meg a kategóriákkal, a megfelelő kulcsmezők mentén. Dupla Equi-Join. Versenyzo INNER JOIN Nevezett ON Versenyzo.id = Nevezett.versenyzoid INNER JOIN Kategoriak ON Nevezett.kategoriaid = Kategoriak.id
-
bpx
őstag
na ezt például kifejezetten nem szeretem a mysql-ben, hogy egyáltalán engedi a group by-t így használni...
(a másik amit utálok, ha nincsenek kiírva az aliasok mindenhol)
egyébként nem csak a vehiclename-mel van gond ha megnézed, hanem a minutes, seconds, milliseconds sem jóSELECT
d.Name,
t.Minutes, t.Seconds, (t.Milliseconds/1000) AS Milliseconds,
x.besttime AS besttime,
r.TrackTitle,
v.VehicleName
From
tracking t,
driver d,
tracks r,
vehicle v,
(select a.driverid, min((a.Minutes*60)+(a.Seconds)+(a.Milliseconds/1000)) as besttime from tracking a group by a.driverid) x
WHERE
d.id = t.driverid
AND t.driverid = x.driverid
AND t.trackid = '1'
AND t.trackid = r.id
AND t.vehicleid = v.id
AND (t.Minutes*60)+(t.Seconds)+(t.Milliseconds/1000) = x.besttime
order by x.besttime; -
Sk8erPeter
nagyúr
Ja értem, így már más a helyzet.
Akkor végül megoldódott a dolog a CONCAT-tal?
Amúgy szerintem az is gáz, hogy ha már eleve nem adnak a kezedbe egy normális dokumentációt az egészről, akkor legalább használnák ki a kommentelési lehetőséget a táblákhoz és annak egyes mezőihez. Azt sem véletlenül találták ki. Mondjuk ritkább, hogy komplex rendszernél az adatbázison belül kommenteket helyeznének el, de akkor jobb esetben legalább van valami doksi az egészről.
-
Sk8erPeter
nagyúr
Eleve azt nem értem, miért URL szerint csoportosítod... Az URL szerinti "összekötéssel" sem értek egyet, nagyon rossz megoldás.
Szerintem az lenne a normális megoldás erre, hogy van mondjuk egy cikked/bejegyzésed, annak pedig van egy id-ja, és egy másik táblában meg az ehhez a cikkhez és id-hoz tartozó kommentek, hozzászólásoko vannak nyilvántartva. A másik, kommenteket tároló táblában tehát tárolod a cikk id-ját is, és ennek segítségével JOIN-olod a két táblát (nem pedig az url mező segítségével; vagy csak simán lekérdezed a cikkhez tartozó kommenteket), így megkapod a cikkhez tartozó kommenteket.
Most a Te comments tábládban nem látok ilyen, a konkrét cikkre vonatkozó id-t, ami jelezné, hogy a kommentek melyik cikkhez tartoznak, az entries táblában viszont látok egy "comments" mezőt. Ennek most nem nagyon értem a szerepét, mert ha ebben felsorolásszerűen vannak a kommentek id-jai, akkor az nagyon rossz megoldás. De lehet, hogy ennek ehhez nincs köze, erről nem írtál, kitalálni meg nehéz.
Viszont ezt az url mezőn keresztüli összekapcsolgatást gyorsan felejtsd el.Az sem világos, hogy ha ennek a két url mezőnek elvileg azonosnak kellene lenni, akkor mi értelme, hogy ebből kettő van... Szerintem átalakításra szorul a táblastruktúrád, vagy most hirtelen csak én nem veszek észre valamit.
-
Apollo17hu
őstag
-
Apollo17hu
őstag
Szia!
Ahhoz mit szólsz, ha fogod a "Comments" táblára megírt lekérdezésed (url és count(*) mezőkkel), amit az "url" mezőn keresztül összekötsz az "Entries" táblából készített lekérdezéssel (ami csak az "url" és a "created" mezőket tartalmazza", majd tolsz az egészre egy DISTINCT-et?
Valahogy így:
SELECT DISTINCT
comments_allekerdezes.url
,comments_allekerdezes.db
,entries_allekerdezes.created
FROM
(SELECT url
,COUNT(*) as db
FROM comments
GROUP BY url) comments_allekerdezes
,(SELECT url
,created
FROM entries) entries_allekerdezes
WHERE comments_allekerdezes.url = entries_allekerdezes.url
ORDER BY entries_allekerdezes.created -
Sk8erPeter
nagyúr
Elég nagy könnyítés lenne, ha megmutatnád a táblaszerkezeteket. Legalábbis most ennyiből nehéz kitalálni, mi szerint kéne joinolni a `comments` táblát is a jelenlegi query-hez, melyik id-nak kell stimmelni. Persze találgatni lehet, de egyszerűbb lenne, ha a konkrét megoldást tudnánk megmutatni, nem?
Ha pl. phpmyadminban rámész az exportra, mutatja a CREATE TABLE... részt (sql dump), abból már elég jól látható lenne a dolog.
-
Brown ügynök
senior tag
-
Kommy
veterán
sikerül átkonvertálnom egy script segítségvel közvetlenül aza eredeti adatbázisból. Igaz több napba kerül a megfelelő script megtalálása , de úgy érzem megérte az egész, így nem kell a weboldalon változtatni. Igaz mág csak sqlite browserban néztemde ott szépen megcsintja az adatbázis remélem fejlesztéskor sem lesz vele gond.
-
rt06
veterán
ugyan nem probaltam (google dobta), de mivel stackoverflow, egy probat meger: Bovebben: link
-
rt06
veterán
"Tehát a kérdés az az, hogy hogyan lehetne az sql-t sqlite-ba konvertálni."
ez a kerdes igy nem ertelmezheto, az sql a "Standard Query Language" roviditese, s a lekerdezesek definialasara valo
az sqlite meg egy konkret rdbms (relational database management system) megvalositasa, ami tobb-kevesebb sikerrel implementalja az SQL-ta kerdes igazabol az, hogy milyen dbms-t hasznalsz a szerveren, s hogy ebbol hogyan lehet atpakolni az adatokat egy sqlite adatbazisba (a valasz meg az, hogy olyan sql utasitasok segitsegevel, amiket megfeleloen kezel mindket dbms-ed, illetve az, hogy esetleg a szerveren is hasznalhatsz sqlite-ot)
Új hozzászólás Aktív témák
Hirdetés
- BESZÁMÍTÁS! Gigabyte H510M i5 10400F 32GB DDR4 512GB SSD RX 5700XT 8GB Rampage SHIVA Zalman 600W
- Üzleti Fujitsu Lifebook u7510 15,6" FHD IPS 2021/08. havi gyártás
- Quadro FX 570 eladó
- Lenovo ThinkCentre M910q Mini PC / i7 7gen/8GB RAM/240GB M2 SSD/12 hónap jótállással
- AKCIÓ! HP USB C G5 Essential (5TW10AA) dokkoló hibátlan működéssel garanciával
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest