Új hozzászólás Aktív témák
-
martonx
veterán
-
Ispy
veterán
A kérdés, hogy minek a 3. tábla? Nem lehet, hogy az csak egy lekérdezés? Vagy minek még 1x letárolni mindent megint? Ez így nem túl adatbázisos megoldás.
Először azt kéne definiálni, hogy pontosan mire akarod azt a táblát használni.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
nyunyu
félisten
Nem teljesen értem, mire való a második táblád.
Ha ebben csak a lehetséges táborozási opciók vannak felsorolva, és a harmadik táblába viszed fel a beérkezéskor, hogy melyik gyerek melyik opciókat kéri, akkor a harmadik táblába csak a gyerek nevét (vagy elsődleges azonosítóját/kulcsát), és az opció azonosítóját kell letárolnod.
Ha a második táblában előre le vannak tárolva, hogy melyik gyerek mit kért (gyerekneve/azonosítója, opció párosként), akkor a harmadik tábla helyett kellene egy lekérdezés vagy nézet, ami ebből egy mátrixot rajzol.
valahogy így:
select nev, vega, reggeli, ebed, vacsora, szamtech, lovas, uszas
from (
select x.nev,
max(x.vega) vega,
max(x.reggeli) reggeli,
max(x.ebed) ebed,
max(x.vacsora) vacsora,
max(x.szamtech) szamtech,
max(x.lovas) lovas,
max(x.uszas) uszas,
from (
select gy.nev,
case when o.opcio = 'Vega' then 'I' else '' end vega,
case when o.opcio = 'Reggeli' then 'I' else '' end reggeli,
case when o.opcio = 'Ebéd' then 'I' else '' end ebed,
case when o.opcio = 'Vacsora' then 'I' else '' end vacsora,
case when o.opcio = 'Számítástechnika' then 'I' else '' end szamtech,
case when o.opcio = 'Lovas' then 'I' else '' end lovas,
case when o.opcio = 'Úszás' then 'I' else '' end uszas,
from gyerekek gy
join opciok o
on o.gyerek_id = gy.id) x --vagy o.nev = gy.nev, ha nevet tárolsz
group by x.nev);Ennek az eredménye egy ilyen táblázat lesz:
NEV VEGA REGGELI EBED VACSORA SZAMTECH LOVAS USZAS
Kiss Péter I I I I
Nagy Anett I
Török Flóra I I I(Bocs, nem nagyon vágom az Accesst, de elvileg szabvány SQL-ben is meg lehet feléje fogalmazni a kéréseket.)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Ispy
veterán
Hun van a selectből a join?
Ezt a where-es megoldást ne erőltesd, én nem legalább is nem szoktam:
update x set mező=...
from x
inner join y on x.mező=y.mező
Így csak azokat fogja frissíteni, ahol x-ben és y-ban is megtalálható a kapcsolat alapján a rekord.
Ez mondjuk nem access, hanem ms sql, már rég nem accesseztem, szerencsére, de hátha megeszi.
Kicsit furán kezeled az accesst, mint valami excel táblát. Nem mint egy relációs adatbázist.
A gyémánt operátor egy kapcsos zárójel (leánykori nevén), ebben az esetben gondolom nincsen from és paraméterként értelemzi az access, egyébként ms sql-ben így illik a mezőkre hivatkozni, mert egyébként ha a mező neve egy operátor is, akkor a fordító nem tudja mit akarsz és hibára fut. Vagy ha gyilkos modon szóköz van a mező nevében, akkor is megpusztul. Ilyenkor a kapcsos zárójel közötti részt mezőként értelmezi.
Egyébként valami ilyesmi is lehet a megoldás:
update x set mező=....
from x, y
where (x.mező=y.mező)
Csak én rosszul vagyok ettől a sytanxistól.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
nyunyu
félisten
Ha nagyon gonosz akarnék lenni, akkor:
UPDATE new_table
SET Parameter1=old_table.Parameter1
WHERE old_table.AzonosParameter = new_table.AzonosParameter;(30+ évvel ezelőtti Teradata szintaxis, még a FROM clause bevezetése előttről.
Kellett nekem ilyenekre SQL parsert írnom adattárház gyakornok koromban. )Ha meg nem akarnék az lenni, akkor:
MERGE new_table u
USING old_table o
ON (u.AzonosParameter = o.AzonosParameter)
WHEN MATCHED THEN UPDATE
SET Parameter1=o.Parameter1;[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Ispy
veterán
Hát passzolom akkor, én amikor accesst használtam akkor is ms sql adatbázis volt mögötte, ilyen hackeket meg soha nem csináltam kézzel, csak VBA-ból max. A beépített varázsló szarokat meg soha nem használtam, mert borzalmasak.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
sztanozs
veterán
Nem biztos, hogy értem, hogy mit szeretnél...
Egyrészt a tűblákat érdemesebb volna ID-val csinálni (mert mi van, ha van két ugyanolyan nevű Kis Péter), de ha eddig nem kézzel volt szinkronizálva a tábla, hanem valami automatizmussal, akkor működhet a mezők "összekötése" utólag is.
Amúgy a harmadik tábla csak egy query lenne, vagy ott is tárolnál valami plusz infót?
Valahogy így raknám össze, ha sokat nem akarnék vacakolni:[ 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...
-
Ispy
veterán
React frontend+express backend? Mi most ezt a kombót használjuk, azure app service-ekkel vagy function appal (serverless). De ez inkább programozás kérdéskör, nem SQL, szóval itt offtopic.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
Új hozzászólás Aktív témák
- Mozilla Firefox
- Premier előzetesen a Gray Zone Warfare
- A tüntetések ellenére is bővítheti német gyárát a Tesla
- Diablo 3
- Ukrajnai háború
- Renault, Dacia topik
- Hővezető paszták
- Google Pixel 6/7/8 topik
- Elcsípte a Huawei kameratelefonja az első helyet
- LG C4 tévé, a népszerű OLED-sorozat legfrissebb tagja
- További aktív témák...
- Galaxy Buds FE - Grafitszürke
- Lenovo ThinkBook 15 G2 ITL, 15,6" FHD IPS Kijelző, i7-1165G7 CPU, 16GB DDR4, 512GB SSD, WIN 11/10, S
- HP Zbook 15 G3, 15,6" FHD IPS Kijelző, I7-6820HQ CPU, 32GB DDR3, 512GB SSD, NVIDIA 4GB VGA WIN 10, S
- Dell Latitude 5480, 14" HD Kijelző, i5-6300U CPU, 8GB DDR4, 256GB SSD, W10, Számla, Garancia
- Dell Latitude 5480, 14" HD Kijelző, i5-6440HQ CPU, 8GB DDR4, 256GB SSD, W10, Számla, Garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest