Új hozzászólás Aktív témák
-
félisten
válasz Brown ügynök #676 üzenetére
Először is kösz a választ, de nem jó a tipp...
Elnézést, csak szétb...sz az ideg ez miatt, és kicsit nagyon leegyszerűsítettem a kérdést. Szóval tudom a hiba okát: az a változó nem létezik 4.1-es mysql előtt. Na most amikor beszéltem az illetékes elvtárssal, érdeklődve többek közt a mysql verzió felől, akkor azt nyilatkozta, hogy a legújabbat használják. Most meg kiderült, hogy 4.0.24-es...A problémát még tetézi, hogy egy fórum motort használtam, ha szerencsém lesz, akkor utólag tudok módosítani 4.0-ás mysql kompatibilitásra...
Nyilván a szolgáltatót nem kötelezhetem, hogy cseréljen mysql-t(bár illene)Szóval a kérdés inkább úgy lett volna jó, hogy van-e valamilyen konverter, bármi, amivel a meglévő adatbázisokat "visszabutíthatnám"...
Még1x, elnézést a nagyon leegyszerűsített kérdésért...
[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
zka67
őstag
válasz Brown ügynök #683 üzenetére
Köszi, de ez nem jó nekem. Azt szeretném, hogy a MySql adja vissza egy mezőben a sorok számát. Olyasmi kellene nekem mint a COUNT() ...
[ Szerkesztve ]
-
sonar
addikt
válasz Brown ügynök #702 üzenetére
Nem igazán jött be
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
biker
nagyúr
válasz Brown ügynök #1211 üzenetére
nincs it semmi gond, az 1-es termékből nem adtál el, ezért az null
a többiből igencsinálj egy harmadik oszlopot a selectbe, amiben a két oszlop különbsége van!
talán így működhet? (vessző kimaradt )SELECT i.product_id, SUM( i.quantity ) , SUM( d.quantity ), (SUM( i.quantity ) - SUM( d.quantity ) ) as diff
FROM `stock_intake_item` i
LEFT JOIN stock_deliver_item d ON d.product_id = i.product_id
GROUP BY i.product_id[ Szerkesztve ]
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
martonx
veterán
válasz Brown ügynök #1213 üzenetére
A kivétel táblát subquery-ként kellene hozzácsapnod, mert így descartes szorzat keletkezik a product_id-k alapján.
Én kérek elnézést!
-
biker
nagyúr
válasz Brown ügynök #1213 üzenetére
ja, bocsi, tényleg
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Apollo17hu
őstag
válasz Brown ügynök #1246 üzenetére
A LEFT JOIN miatt van: a stok_intake tábla minden rekordja bekerül. Használj helyette INNER JOIN-t, ami a táblák metszetét adja eredményül.
-
Apollo17hu
őstag
válasz Brown ügynök #1248 üzenetére
Akkor a stock_product_history táblában nincs olyan rekord, ahol az intake_id beköti a stock_intake, a reservation_id pedig a stock_reservation táblát.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Brown ügynök #1250 üzenetére
Kellene egy mező, ami megmondja, hogy a stock_product_history táblában mely intake_id-k mely reservation_id-kkal vannak kapcsolatban. (Kapcsolat esetén a mező értékének egyeznie kell a két rekordnál.)
Szerintem ezt lehet egyszerűsíteni, de nem teljesen értem, hogy mi a végcél. Talán egy olyan táblából kellene kiindulni, ahol az intake_id és a reservation_id egy soron szerepelnek, és csak akkor vannak töltve, ha a tényleges esemény (bevitel vagy foglalás) megtörtént. Nem tudom, hogy az események között van-e valamiféle időbeli sorrendiség, de előfordulhat, hogy mondjuk volt már foglalás, de azt nem vitték még be (ekkor utóbbi értéke null). Vagy az intake nem erre vonatkozik?
Ha ez tisztázódott, utána lehet a product, store stb. mezőket hozzáadni a modellhez.
-
Apollo17hu
őstag
válasz Brown ügynök #1253 üzenetére
Akkor szerintem 2 tábla kellene:
BEVITEL: termék | mikor | mennyit
FOGLALÁS: termék | mikor | mennyitEzeket "termék"-en keresztül kötöd össze, a két "mikor"-ra szűrsz, a "mennyit" mezőt pedig aggregálod (GROUP BY).
Egy táblában is meg lehetne oldani (ahogy neked most a főtáblád tárolja az adatokat) kötések nélkül:
TÁBLA: termék | bevitel_mikor | bevitel_mennyit | foglalás_mikor | foglalás_mennyit
Ebben az esetben viszont vagy a "bevitel_mikor" és "bevitel_mennyit" vagy a "foglalás_mikor" és "foglalás_mennyit" mezők értéke lenne null, tehát feleslegesen nőne az adatbázis mérete.
A lényeg, hogy termékazonosítón keresztül lenne célszerű kötni.
-
Apollo17hu
őstag
válasz Brown ügynök #1256 üzenetére
Első ránézésre nem igazán menő, hogy IN után allekérdezést használsz. Ha kicsit több időm lesz, megnézem a kódot, de ha az eredmény jó neked, akkor nagy gond nem lehet.
-
Apollo17hu
őstag
válasz Brown ügynök #1256 üzenetére
A stock_intake_item és a stock_intake táblát összevonhatnád. Utóbbi csak egy időpecsétet tartalmaz, felesleges szétszedni. Lenne a kettőből egy táblád, ami megmutatja, hogy adott napon adott termékből hány darab került be.
Hasonlóan kellene tenni a stock_reservation_item és stock_reservation táblákkal.
IN helyett elvileg JOIN-olhattad volna a stock_intake táblát. Úgy, ahogy a stock_reservation táblát is bekötötted.
-
válasz Brown ügynök #1303 üzenetére
Elsőre szar lekérdezések (és indexek), illetve rosszul beállított szerver. Az a baj, hogy ezt már tényleg látni kellene.
-
martonx
veterán
válasz Brown ügynök #1306 üzenetére
Mondjuk jobban utána gondolva az e pont azért okozhat némi teljesítmény problémát (MySQL sosem volt sebesség bajnok, pláne nem a korai verziói), illetve bizonyos esetekben a d pont is bezavarhat, bár ezt nem tartom túl valószínűnek.
Én kérek elnézést!
-
válasz Brown ügynök #1306 üzenetére
Ha már optimalizálás, ma találkoztam egy problémával, egy drop down list-et, amiben 2000 elem volt kb. 8000 SQL lekérdezéssel (mindegyikhez volt 4) töltött fel egy hülyegyerek. Újraírtam, hogy lejöjjön egyben.
-
martonx
veterán
válasz Brown ügynök #1312 üzenetére
Azt azért tartsd észben, hogy a MySQL optimalizációnál erősen meglőnek, ha eleve nem jól beállítva telepítik fel.
Úgyhogy vagy neked kell egyben a rendszergazdának, DBA-nak is lenned, vagy utólag simán előfordulhat az az eset, hogy marhára nem fogsz tudni mit optimalizálni, mert a telepítéskor elcseszett setup miatt egyszerűen mindeféle diagnosztizáló funkció le van tiltva rajta.
És ezeken utólag nagyon nem szeretnek a rendszergazdák változtatni.Én kérek elnézést!
-
martonx
veterán
válasz Brown ügynök #1314 üzenetére
Ez sok mindentől függ. Mennyire komplex például az index, mennyi indexed van a táblán stb...? Ha komplex, és sok az index akkor az írást lassítja.
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Az írás tűnik lassúnak vagy az olvasás? Mert ha az olvasás a lassú, akkor viszont mindenképpen kell az index, különben nélküle meg megállna az élet. Még ha ez miatt némileg lassul is az írás.
Szóval igazán jó válasz nem biztos, hogy van a kérdésedre.
Kérdés az is, hogy mit értesz azonos mennyiségű írás, olvasásnak? Naponta 100 sort beírsz, és 100 sort ki is olvasol? Vagy hogy naponta 100-szor olvas valamit a táblából, és 100-szor ír valamit a táblába a db motor? Ez esetben a valamit az érdekes, hogy 100-szor beír 1 sort, vagy 100-szor beír 2000 sort?
Ez esetben pl. az írási stratégiáján a programnak érdemes lehet változtatni.Én kérek elnézést!
Új hozzászólás Aktív témák
- AKCIÓ Új Dobozos Macbook Pro dokkoló új ára 70.000 forint
- ThinkPad Hybrid USB -C USB -A Dock 40AF Új ára 80.000 Forint Ingyen szállítás
- Xiaomi Redmi Note 9s 128/6 GB 34.9E !!!
- Új Hp Pavilion 15-eh Fémházas Szuper Laptop 15,6" -30% AMD Ryzen 7 5700U 8Mag 16/1TB FHD MATT
- ATI RADEON RX 480 -8 gb DDR5 256 bit videokártya