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

• #1316 Brown ügynök senior tag martonx #1315

  Új Válasz 2013-06-28 11:27:42 #1316

  Ú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

  

  Brown ügynök

  senior tag

  válasz martonx #1315 üzenetére

  Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.

  Akkor ez azt jelenti, ha egy adatbázisban megfelelőn használjuk az idegen kulcsokat az nagy mértékben hozzájárul a teljesítmény növeléséhez?

  Ahogy elnéztem egyébként, inkább az indexek hiánya lehet a ludas, mint a túl nagy száma. Úgy látom, ez egy összetett kérdés... Egyébként az program szinten nem akarok nagyon belenyúlni, mert elég mosott a kód. Igyekszem adatbázis oldalról javítani (ha lehet). Az igazi megoldást persze egy egészséges újraírás jelentené (és nem csak a lassú lekérdezések miatt).

• #1314 Brown ügynök senior tag martonx #1313

  Új Válasz 2013-06-28 09:39:11 #1314

  Ú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

  

  Brown ügynök

  senior tag

  válasz martonx #1313 üzenetére

  A query loghoz nem férek hozzá, de szerintem ha szépen megkérem az adminisztrátort, rendelkezésemre bocsátja. Egyébként az "explain" kulcsszóval próbálkozom.

  Egyébként ha egy táblába nagyjából azonos mennyiségben írunk és olvasunk, azt érdemes indexelni?

• #1312 Brown ügynök senior tag Peter Kiss #1310

  Új Válasz 2013-06-27 17:12:37 #1312

  Ú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

  

  Brown ügynök

  senior tag

  válasz Peter Kiss #1310 üzenetére

  Ilyen lekérdezéssel szerencsére én még nem találkoztam.

  @martonx: Átnéztem a táblákat és nincs olyan nagy vegyítés a motoroknál.

  Egyébként októberben költözik a cucc modernebb vasra, addig nézek valami okosságot a MySQL optimalizációjáról szóló fejezetében.

• #1306 Brown ügynök senior tag

  Új Válasz 2013-06-27 09:17:07 #1306

  Ú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

  

  Brown ügynök

  senior tag

  @Athlon64+, @martonx: Akkor jobban elmerülök az indexelésben. Ez az a pont amin most könnyen javíthatok. (Egyébként nem tudom milyen vas szolgálja ki a rendszert, ennek majd utánaérdeklődöm.)

• #1303 Brown ügynök senior tag

  Új Válasz 2013-06-26 20:44:04 #1303

  Ú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

  

  Brown ügynök

  senior tag

  Adott egy adatbázis kb. 200 táblával, melyet egyszerre maximum 10-15 használnak. Az itt felsoroltak közül melyek okozhatják a "slow query"-ket (illetve, hogy a rendszer többször érezhetően kegyelemért könyörög)?

  a) Az egyik tábla 23 millió rekordot tartalmaz (a többi, 2 kivételével általában pár tízezret)

  b) Optimalizálatlan lekérdezések

  c) Adatbázis tervezési hibák

  d) InnoDB, MyIsam vegyesen

  e) Elavult MySQL verzió (5.1.49)

  f) A MySQL ennyit bír

  g) Vashiány

  h) C-vitamin hiány

• #1260 Brown ügynök senior tag Apollo17hu #1259

  Új Válasz 2013-05-24 11:50:13 #1260

  Ú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

  

  Brown ügynök

  senior tag

  válasz Apollo17hu #1259 üzenetére

  A stock_intake tábla egy store_id-t is tartalmaz. Na, inkább megmutatom a táblákat.

  intake
  id, name, store_id, available, created, updated

  intake_item
  id, intake_id, product_id, quantity

  reservation
  id, name, created, completed

  reservation_item
  id, reservation_id, intake_id, product_id, quantity

  product_history
  id, product_id, intake_id, reservation_id, store_id, created

  Most úgy oldottam meg, hogy a product_history táblába felvettem a mennyiséget és a teljesülés dátumát (amikor ténylegesen ki/bevitték a raktárba az árut). Kvázi tehát kétszer lesz meg az adat, de nem tudtam máshogy megoldani, hogy a teljesülés dátuma szerint rendezze a bevitel és kivétel sorait a lekérdezésben. A product_history a változtatások után:

  product_history
  id, product_id, intake_id, reservation_id, store_id, quantity, created, completed

  A lekérdezés:

  SELECT h.id, h.completed, quantity, r.name reservation_name, i.name intake_name,
  i.created intake_created, r.created reservation_created
  FROM stock_product_history h
  LEFT JOIN stock_intake i ON i.id = h.intake_id
  LEFT JOIN stock_reservation r ON r.id = h.reservation_id
  AND r.completed BETWEEN :from AND :to
  WHERE h.product_id = :productId
  AND h.store_id = :storeId
  AND h.completed BETWEEN :from AND :to
  ORDER BY h.completed

• #1256 Brown ügynök senior tag Apollo17hu #1254

  Új Válasz 2013-05-24 10:05:57 #1256

  Ú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

  

  Brown ügynök

  senior tag

  válasz Apollo17hu #1254 üzenetére

  Így már csak azokkal a beviteli és foglalási sorokkal tér vissza amik a megadott intervallumba esnek. Csak az a baj, hogy nem a product_history tábla created oszlopa szerint rendezi őket (gondolom a group by miatt). Úgy látom szinte az összes adatot be kell szúrnom az intake és a reservation táblából, hogy időrendben meg tudjam jeleníteni a mozgásokat... Köszi a segítséget!

  SELECT *
  FROM stock_product_history h
  LEFT JOIN stock_intake_item it ON it.product_id = h.product_id
  AND h.reservation_id is NULL
  AND it.intake_id IN (SELECT id
  FROM stock_intake
  WHERE available BETWEEN :from AND :to
  AND store_id = :storeId)
  LEFT JOIN stock_intake i ON it.intake_id = i.id
  AND i.available BETWEEN :from AND :to
  LEFT JOIN stock_reservation_item ri ON ri.product_id = h.product_id
  AND ri.reservation_id = h.reservation_id
  LEFT JOIN stock_reservation r ON r.id = ri.reservation_id
  AND r.completed BETWEEN :from AND :to
  WHERE h.product_id = :productId
  AND h.store_id = :storeId
  GROUP BY ri.id, i.id
  ORDER BY h.created ASC

• #1253 Brown ügynök senior tag Apollo17hu #1252

  Új Válasz 2013-05-23 18:00:16 #1253

  Ú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

  

  Brown ügynök

  senior tag

  válasz Apollo17hu #1252 üzenetére

  A végcél az, hogy adott időszakra vonatkozóan megkapjuk egy termékről a raktári beviteleket (intake) és a teljesített foglalásokat (reservation) ami ez esetben a raktár kivétel lesz. Az i.available jelzi, hogy mikor van az áru ténylegesen a raktárban, a r.completed pedig azt, amikor teljesült a foglalás vagyis elvitték az árut. Foglalni a bevitelből lehet, tehát az intake_id a reservation táblában megvan.

• #1250 Brown ügynök senior tag Apollo17hu #1249

  Új Válasz 2013-05-23 15:15:46 #1250

  Ú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

  

  Brown ügynök

  senior tag

  válasz Apollo17hu #1249 üzenetére

  Valóban. Jelenleg úgy van megoldva, hogy egy sorban vagy az intake_id vagy a reservation_id mező van kitöltve a stock_product_history táblában. Megnéztem, ha egy oszlopba írom őket egy másikba meg a típust adom meg és úgy kérdezem le, akkor is ugyanaz lesz az eredmény (gondolom az előző ok miatt). Igazából egy cikktörténetet szeretnék lekérdezni az intake(_item) és a reservation(_item) táblák csatolásával. Hogy alakítsam át a lekérdezést vagy a stock_product_history táblát, hogy úgy működjön, ahogy szeretném? Meg lehetne ezt oldani stock_product_history tábla nélkül is?

• #1248 Brown ügynök senior tag Apollo17hu #1247

  Új Válasz 2013-05-23 14:02:08 #1248

  Ú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

  

  Brown ügynök

  senior tag

  válasz Apollo17hu #1247 üzenetére

  INNER-rel jó is lenne de akkor a reservation(_item) tábla sorait akkor nem kapcsolja hozzá.

• #1246 Brown ügynök senior tag

  Új Válasz 2013-05-23 13:21:25 #1246

  Ú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

  

  Brown ügynök

  senior tag

  Segítséget szeretnék kérni a következő lekérdezéshez:

  SELECT *
  FROM stock_product_history h
  LEFT JOIN stock_intake i ON h.intake_id = i.id
  AND i.available BETWEEN :from AND :to
  LEFT JOIN stock_intake_item it ON it.intake_id = i.id
  AND it.product_id = :productId
  LEFT JOIN stock_reservation r ON r.id = h.reservation_id
  AND r.completed BETWEEN :from AND :to
  LEFT JOIN stock_reservation_item ri ON ri.reservation_id = r.id
  AND ri.product_id = :productId
  WHERE h.product_id = :productId
  AND h.store_id = :storeId
  GROUP BY ri.id, i.id

  Azt szeretném elérni, hogy az intake_item és a reservation_item táblából csak azokat csatolja, amelyek megfelelnek intake és a reservation táblánál felállított dátum (available, completed) követelményeknek. Ezzel a lekérdezéssel olyan intake_item sort is kapok ami kívül esik az available tartományán ( bár minden értéke 0 vagy null).

• #1216 Brown ügynök senior tag martonx #1214

  Új Válasz 2013-05-07 09:58:26 #1216

  Ú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

  

  Brown ügynök

  senior tag

  válasz martonx #1214 üzenetére

  Köszi, így már működik:

  SELECT i.product_id, SUM( i.quantity ) ,
  ( SELECT SUM( quantity )
  FROM stock_deliver_item
  WHERE product_id = i.product_id
  ) AS deliver
  FROM `stock_intake_item` i
  GROUP BY i.product_id

  Hogy NULL-al is működjön a subqueryben az IFNULL() függvényt lehet használni.

• #1213 Brown ügynök senior tag biker #1212

  Új Válasz 2013-05-07 09:23:06 #1213

  Ú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

  

  Brown ügynök

  senior tag

  válasz biker #1212 üzenetére

  Nem írtam le teljesen... Szóval a 6. terméket dupla annyinak számítja mint amennyi valójában van. A diff azért nem jó mert ha NULL-t próbálok kivonni, NULL lesz az eredmény.

• #1211 Brown ügynök senior tag

  Új Válasz 2013-05-07 09:03:20 #1211

  Ú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

  

  Brown ügynök

  senior tag

  Van két táblám, egy a raktári bevételezést, a másik pedig a kivételt mutatja. Ennek a kettőnek az összességéből megkapjuk a raktárkészletet. Íme a két tábla:

  Bevételezés

  

  Kivétel

  

  Ez a lekérdezés a vártnak megfelelően működik:

  SELECT product_id, SUM( quantity )
  FROM `stock_intake_item`
  GROUP BY product_id

  

  Ha viszont hozzácsapom a kivétel táblát:

  SELECT i.product_id, SUM( i.quantity ) , SUM( d.quantity )
  FROM `stock_intake_item` i
  LEFT JOIN stock_deliver_item d ON d.product_id = i.product_id
  GROUP BY i.product_id

  

  Mi lehet a gond? Illetve, ilyen esetekben érdemes-e csinálni egy harmadik táblát ami tulajdonképpen az aktuális készletet tárolnánk?

• #702 Brown ügynök senior tag sonar #699

  Új Válasz 2011-09-11 10:19:07 #702

  Ú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

  

  Brown ügynök

  senior tag

  válasz sonar #699 üzenetére

  A date_sub után nem kell space.

• #683 Brown ügynök senior tag zka67 #682

  Új Válasz 2011-08-11 12:09:34 #683

  Ú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

  

  Brown ügynök

  senior tag

  válasz zka67 #682 üzenetére

  MySql:[link]
  MySQLi: [link]

• #676 Brown ügynök senior tag Fire/SOUL/CD #675

  Új Válasz 2011-07-04 17:56:19 #676

  Ú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

  

  Brown ügynök

  senior tag

  válasz Fire/SOUL/CD #675 üzenetére

  Tipp: Automatikusan kitöltött mező, melynek értéke nem lehet 0 / értéket kell adni?

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