Új hozzászólás Aktív témák

• #1315 martonx veterán Brown ügynök #1314

  Új Válasz 2013-06-28 10:40:55 #1315

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1313 martonx veterán Brown ügynök #1312

  Új Válasz 2013-06-28 08:32:25 #1313

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1310 Peter Kiss őstag Brown ügynök #1306

  Új Válasz 2013-06-27 15:34:30 #1310

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Peter Kiss

  őstag

  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.

• #1307 martonx veterán Brown ügynök #1306

  Új Válasz 2013-06-27 10:05:24 #1307

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1304 Peter Kiss őstag Brown ügynök #1303

  Új Válasz 2013-06-26 21:05:43 #1304

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Peter Kiss

  őstag

  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.

• #1259 Apollo17hu őstag Brown ügynök #1256

  Új Válasz 2013-05-24 11:28:53 #1259

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1258 Apollo17hu őstag Brown ügynök #1256

  Új Válasz 2013-05-24 11:04:54 #1258

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1254 Apollo17hu őstag Brown ügynök #1253

  Új Válasz 2013-05-23 18:31:53 #1254

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 | mennyit

  Ezeket "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.

• #1252 Apollo17hu őstag Brown ügynök #1250

  Új Válasz 2013-05-23 16:37:24 #1252

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1249 Apollo17hu őstag Brown ügynök #1248

  Új Válasz 2013-05-23 14:43:18 #1249

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1247 Apollo17hu őstag Brown ügynök #1246

  Új Válasz 2013-05-23 13:41:51 #1247

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1215 biker nagyúr Brown ügynök #1213

  Új Válasz 2013-05-07 09:48:18 #1215

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  biker

  nagyúr

  válasz Brown ügynök #1213 üzenetére

  ja, bocsi, tényleg

• #1214 martonx veterán Brown ügynök #1213

  Új Válasz 2013-05-07 09:44:57 #1214

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1212 biker nagyúr Brown ügynök #1211

  Új Válasz 2013-05-07 09:11:22 #1212

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 igen

  csiná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

• #703 sonar addikt Brown ügynök #702

  Új Válasz 2011-09-12 11:15:11 #703

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sonar

  addikt

  válasz Brown ügynök #702 üzenetére

  Nem igazán jött be

• #684 zka67 őstag Brown ügynök #683

  Új Válasz 2011-08-11 12:25:35 #684

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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() ...

• #677 Fire/SOUL/CD félisten Brown ügynök #676

  Új Válasz 2011-07-04 18:13:35 #677

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Fire/SOUL/CD

  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...

Új hozzászólás Aktív témák