Hirdetés
- Luck Dragon: Asszociációs játék. :)
- talmida: My Art II.
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Viber: ingyen telefonálás a mobilodon
- eBay-es kütyük kis pénzért
- Doky586: SecureBoot kulcsok frissítése (2026 nyara)
- GoodSpeed: Daikin FTXF35E / RXF35F Sensira 3,3 kW Inverteres klíma - a Sztori
- mefistofeles: Az elhízás nem akaratgyengeség! 2 Ahogy én csinálom.......
- MasterDeeJay: Comet lake (10gen) és DDR3 - mert ilyet is lehet!
Új hozzászólás Aktív témák
-
Sokimm
senior tag
Sziasztok!
A MsAccess fórum elég kihaltnak tűnik, ezért itt tenném fel a kérdésem:
Van egy gyermektábor, amiben 3 tábla adja az adatbázist.
Az első tábla, a gyerekek neve, szülők kapcsolattartó elérhetősége, extra adatai vannak.
A második tábla, a gyerekek egyedi táboros igényeit taglalja (vega, hány napot van, melyik foglalkozás érdekli, stb).
A 3. táblába szeretném a gyerekek információs táblájából kinyerni CSAK a nevüket, és mellé a második tábla opciós mátrixát dinamikusan hozzáilleszteni. (táborba érkezés regisztrációkor név: mit kér enni, mire jött, stb)
A problémám az, hogy míg az adatok lookup table szerű dinamikus változói szépen létrejönnek, addig a gyerekeket egyesével kell a rekordok közé felvenni, és rohadt fárasztó 100 gyereknél.
Van rá valami mód, hogy a recordokat autofill módon feltöltse az első táblából?
Később jöhet még 1-1 gyerek, azokat már manuálisan hozzáadnám a 3. táblához, de a tömeget nem szeretném egyesével.
Ha ez túl Microsoft-os téma (szintaktika acces szinten), akkor kérlek ne haragudjatok, viszont ha szemantikailag (lehetetlen teljes adattáblákból oszlopok "copy"-ja másik táblában adatbáziskezelő programokban) vagyok lemaradva, kérlek világosítsatok fel, miként oldanátok meg a problémám.
A válaszokat előre is köszi. -
Taci
addikt
Adott ugyanaz a témakör, ami korábban is.
A kérdésem a következő lenne:Adott példának okáért ez a lekérdezés: DB Fiddle
Itt ami fontos lenne nekem, hogy ha egy kategóriára azt mondom, hogy nem érdekel (
category_id not in (27)), akkor azokat az elemeket ne jelenítse meg, amikhez ez a kategória hozzá van rendelve. (Pl. ha azt mondom, allergiás vagyok a mogyoróra, akkor ne mutasson olyan recepteket, amiben mogyoró van)Ezzel az adott lekérdezéssel viszont nem így működik.
Direkt úgy módosítottam a példát, hogy könnyen látni lehessen:INSERT INTO `items_categories` (`id`, `item_id`, `category_id`) VALUES(349, 117, 27),(350, 117, 26),(351, 117, 29)Tehát 117-es elem benne van a 27-es, 26-os és a 29-es kategóriában.
Ha én azt kérem, hogy azokat az elemeket ne jelenítse meg, amik a 27-es kategóriába tartoznak (
category_id not in (27)), azt várnám, hogy a 117-es elemet nem jeleníti meg egyáltalán.Viszont ebben a formájában ez nem így működik, mert ezzel csak azt érem el, hogy eredménybe visszaadja a 117-est is, mert a 3 rekordból kizárja azt az egyet, ami a 27-es kategóriás, viszont a maradék kettő miatt a találati listában marad.
Hogyan lehet megoldani ezt?
Köszönöm.
-
pch
senior tag
Ha már mysql lenne egy kérdésem
Van egy tábla amibe a dátumok vannak (meg egyéb adatok, de ez most nem lényeg)
Van egy másik tábla amibe egy adott dátumhoz hozzá van fűzve egy érték.
Meg van egy harmadik tábla amibe van egy kezdőérték.
Melyik az a számolási metódus amivel a kezdőértékhez ha hozzáadom a dátumnál letárolt értéket az lesz a következő kezdőérték, és ha talál egy későbbi dátum<>értéket azt az előzőhöz adja hozzá?
php alatt ugye a x=x+y
Azaz egyik táblába vannak mondjuk a hónap-napok egymás után (2021-08-01 ... 2021-08-31)
Másik tábla (2021-08-20 1500) (2021-08-23 3500)
A harmadik táblába az induló 5000
Akkor ezt szeretném kapni:
2021-08-01 től 2021-08-19 ig 5000,
utána 6500
majd 23-tól 10000
Köszönöm! -
nyunyu
félisten
Azt ne felejtsd ki a képletből, hogy a count() lekérdezésnek a végeredménye egy szám, míg a count() nélkülié egy adathalmaz, aminek a DB szerverről letöltése lényegesen tovább tart.
Tegnap kellett lementenem egy 850k soros táblához kapcsolódó adatokat CSVbe, eltartott vagy 20 percig, mire lejött a 160 mega adat a céges VPNről.
Ugyanez select count(*) from (eredeti query)-vel 5 másodpercig tart. -
Taci
addikt
Lehet, triviális a válasz, de:
Egy Count-lekérdezés végrehajtása ugyanannyiba kerül, mint pont ugyanannak a query-nek a Count nélküli változata?
Azért merült fel a kérdés, mert ha a Count nélkülivel eleve megkapom magukat az elemeket is, akkor ha csak a Count-ban tér el a két query, abban az esetben nincs értelme a Count-ot használni, hisz' az csak az elemek számát adja vissza, míg a másikkal megkapom az elemeket is, amiket aztán meg összeszámoltatok egyszerűen.
(Nyilván lehet millióféleképpen használni, én sem csak így használom, de amikor pont ilyen eset lenne, hogy a Count-on kívül minden más ugyanaz, akkor vajon ugyanannyi időt vesz igénybe mindkét lekérdezés? Tippem szerint igen, hisz' ugyanúgy kell elvégezni minden műveletet benne, így a Count csak összeszámolja az eredménytáblát "és kész".
De most már inkább rákérdezek.)
-
-
Taci
addikt
Sosem találkoztam még vele, úgyhogy ránéztem. És itt azt taglalják, hogy az SQL_CALC_FOUND_ROWS általában véve lassabb, mint a két külön query (az eredeti + a count).
Plusz ahogy olvasom, a jövőbeli verziókból már ki is szedik a támogatottságát:
The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be removed in a future MySQL version.
És hogy a COUNT(*)-ot ajánlják helyette.Köszönöm azért a tippet, legalább láttam, hogy ilyen is van (lassan: volt).
-
Taci
addikt
Illetve még azt kérdezném külön témaként, elméleti kérdésként:
Eddig úgy csináltam, hogy kértem 4 elemet (query, Limit 4), a kliens felhasználta, kért újabb 4 elemet, felhasználta és így tovább.
Tehát 4 elemenként volt egy query az adatbázisból. Per kliens.
Ez azért volt jó (inkább kényelmes), mert abban a pillanatban, hogy nem 4 elemet kapott a kliens vissza, megvolt, hogy nincs több elem, jöhet a no_more_items elem.Most azt nézem, hogy a Limit 64-gyel egyből betöltök 64 elemet. Ez nyilván 16-szor több (szöveges) adatot jelent egyben, viszont így is csak kb. 30 kB a Limit 4-nek a kb. 2 kB-jával szemben. 30 kB-nyi adat pedig semmi, és ezzel a query-k számát is drasztikusan leredukálhatom. (4 elemenkéti lekérdezés helyett csak 64 elemenkénti).
Viszont ezzel egy teljes szerkezeti változást meg kell csinálnom a PHP és a JS fájljaimban is. Amit persze szó nélkül megteszek, csak szeretnék előbb tanácsot kérni, hogy melyik a jobb út. Vagy van-e egy harmadik út, ami még jobb lenne.
Ha a szervernek "nem fáj" az ilyen sűrű lekérdezés (és nem is lassítja - több ezer felhasználó egyidejű lekérdezéseit figyelembe véve sem), akkor maradok a Limit 4-nél.
De ha ez a sűrű lekérdezgetés rossz hatással van a válaszidőre, és ezzel a felhasználói élményre is, akkor nézegetem a másik utat, hogy egyszerre több adatot kérek le, és az utolsó pár elemig azzal eldolgozgat a kliens lokálban, aztán a vége felé kéri az újabb adagot.
Vagy van valami más, jobb út?
Köszönöm.
-
Taci
addikt
válasz
sztanozs
#5140
üzenetére
Ha az általad írt lekérdezés által visszaadott össz-elemszámot szeretném megtudni (a belső limit nélkül - hogy később tudjak vele számolni, a belső limit meddig nyújtózkodhat - szóval a belső Select-et ezért veszem ki, plusz ugye nem kell rendezni sem (Order By), és a végén lévő Limit sem kell)), akkor jelen tudásom szerint azt így kérdezném:
SELECT COUNT(*) AS result_count FROM(SELECT i.item_id FROM items AS iINNER JOIN items_categories AS c ON i.item_id=c.item_idWHEREc.category_id NOT IN (1,3,13,7,20) ANDi.item_id NOT IN (117,132,145,209,211)GROUP BY i.item_id) AS tVan esetleg ennek hatékonyabb, gyorsabb, jobb módja?
Ezt találtam még:
SELECT COUNT(DISTINCT item_id) AS result_count FROM(SELECT i.item_id FROM items AS iINNER JOIN items_categories AS c ON i.item_id=c.item_idWHEREc.category_id NOT IN (1,3,13,7,20) ANDi.item_id NOT IN (117,132,145,209,211)) AS tItt elvileg a Distinct kiváltja a Group By-t.
Viszont sajnos Count-hoz a phpMyAdmin nem ír lekérdezési időt, így nem tudom, melyik a gyorsabb. Vagy jobb.
Ebben kérnék tanácsot.
Köszönöm. -
-
válasz
bambano
#5156
üzenetére
Ez viszont nem jól fogja számolni, lesz egy nap két DE (2*8 óra, hajnalban és éjszaka) és egy DU (1*16 óra napközben).
Valahogy így lehet jó:
SELECT
TRUNC(dateadd(hour,-8,datum)) AS nap,
CASE WHEN date_part('hour',dateadd(hour,-8,datum))>12 THEN 'DU' ELSE 'DE' END AS muszak,
SUM(szam)
FROM tabla
GROUP BY 1,2 ORDER BY 1,2;Így a hajnal még az előző naphoz fog tartozni mint DU műszak.
-
tm5
tag
válasz
bambano
#5150
üzenetére
SELECT TRUNC(datum) AS nap,
CASE WHEN DATEPART(HOUR,datum)>11 THEN 'DU' ELSE 'DE' END AS napszak,
SUM(szam) AS osszeg
FROM tabla
GROUP BY nap,
CASE WHEN DATEPART(HOUR,datum)>11 THEN 'DU' ELSE 'DE' END
ORDER BY 1,2
Legyen neked Karácsony Nálunk 12 és 1 között ebéd szünet van, olyan senkiföldje.
Van rá valami mód, hogy a recordokat autofill módon feltöltse az első táblából?
Új hozzászólás Aktív témák
- Hardcore pizza és kenyér topik
- MWC 2026: Hálózattechnológiai mélyvíz Bóday Tamással. Mint rendesen.
- Jogász topik
- Android alkalmazások - szoftver kibeszélő topik
- ASUS routerek
- Luck Dragon: Asszociációs játék. :)
- Mini-ITX
- VGA kibeszélő offtopik
- exHWSW - Értünk mindenhez IS
- PlayStation 5
- További aktív témák...
- Komplett RGB Gamer PC / RTX 3080 / i5-12490F / 32GB DDR5 / 250GB & 1TB SSD / IRÁNYÁRAS
- Magyar kiosztású Apple Magic Keyboard 2, Touch ID, teljes méretű
- Új Mac Studio M4 Max 2025 14C CPU /32C GPU / 36GB RAM / 512GB - 1 ÉV APPLE GARANCIA
- 2026 MacBook Air / MacBook Pro / M5 - M5 Pro - M5 MAX 14" / 16"
- Asus 15.6,core i3 8145U(4x3,9Ghz)IntelUHD VGA,MAGYAR Vil.bill.,8-20GB RAM,SSD+HDD?,,Win.11
- Apple iPhone 17 Pro Max 256GB Deep Blue használt, újszerű 100% akku (0 ciklus) 12 hónap gar
- Gamer egerek és billentyűzetek kitűnő árakon!
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
- HIBÁTLAN iPhone 14 Pro Max 256GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4370
- Dobozos Új HP OmniBook 5 Flip 2-in-1 érintőkijelzős laptop i5-1334U 16gb ram 512ssd Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest