Aktív témák

• #2092 Sk8erPeter nagyúr wolandino #2091

  2012-04-28 15:17:05 #2092

  Ö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

  

  Sk8erPeter

  nagyúr

  válasz wolandino #2091 üzenetére

  Mivel nem konkretizáltad a dolgot, magunktól nehéz kitalálni, hogy ha egyszer a felhasználó töröl, akkor mindenhonnan törölnie kellene a dolgokat, vagy pl. az összekapcsoló táblában mondjuk csak be kéne rakni egy NULL-t az egyik mezőhöz, jelezvén, hogy pl. az adott elemnél hiányzik egy "párosítás", még a hozzákapcsolásnak csak az "egyik fele" van meg, és lehetne még pár lehetséges változatot kitalálni.
  Nem egyértelmű tehát, hogy miket jelölhet törlésre... olyan eset is elképzelhető, hogy a bejegyzéseket egyszerűen csak az összekapcsoló táblából kellene törölni, tehát akkor egyedül az összekapcsoló táblában nyilvántartott id-k közül kellene választania a júzernek (nyilván a hozzátartozó felhasználóbarát adat segítségével, ne id-k közül válogasson). Akkor meg egyértelmű: szűkíted a törlést arra az id-re a kapcsoló táblából, amit a júzer kiválasztott, és megvagy. De mondom, nem specifikáltad a problémát.

• #2014 bLaCkDoGoNe veterán wolandino #2009

  2012-02-07 17:30:56 #2014

  Ö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

  

  bLaCkDoGoNe

  veterán

  válasz wolandino #2009 üzenetére

  Mi lenne akkor, ha nem tárolnád el egy adott év összes napját, hanem csak a munkaszüneti napokat tárolnád el minden hónapra? (Lehet, hogy félreértettem a metódusodat, és ez így nem elég neked.)

• #2013 Sk8erPeter nagyúr wolandino #2009

  2012-02-07 17:01:33 #2013

  Ö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

  

  Sk8erPeter

  nagyúr

  válasz wolandino #2009 üzenetére

  1.) itt a százalék helyett miért nem valami jobban kalkulálható egységgel dolgozol? Például a meló mértéke lehetne inkább óra egységben megadva: adott hónapban X órát dolgozott. Persze ettől függetlenül lehetne pluszban egy mező, hogy ez most 100%-ot, vagy 432%-ot jelent, bár lehetne ezt is másképp megoldani, ez már egyéni döntés kérdése.

  2.) hmm, itt most gyorsan átfutva nem jut eszembe hirtelen más, mint hogy minden naptári napot eltárolni - tulajdonképpen muszáj, hiszen minden napra más adat vonatkozik.
  Mivel minden naptári naphoz tartozhat általános, mindenkire érvényes adat is, esélyes, hogy egy külön táblában kellene tárolni a naptári napokat,és ezek id-jaihoz kapcsolni az egyes dolgozók napokra lebontott adatait. Szerintem csak így tudsz minden adatot jól követhetően tárolni, hogy minden évre, napra, dolgozóra rá lehessen külön keresni, és viszonylag általános legyen a szerkezet. Még ha sok adat is lesz ezzel, több táblában, és dolgozónként hivatkozni kell a naptári napok id-jaira az év összes napján...
  Nem kell minden évnek külön tábla, egy szerintem elég, ahol az összes naptári nap szerepel, aztán lehet, hogy van erre megfelelő ellenérv. De ilyen esetben mindenképp érdemes szerintem különbontani a dátum egyes adatait, tehát akár évet, hónapot, napot, bizonyos dátum szerinti kereséseknél tudtommal ez hatékonyabb is lehet, mert nem kell mindig dátumkonverziós függvényeken keresztülverni az egész dátumot.

  Most nem gondoltam végig minden lehetőséget, tehát remélem még valaki hozzátesz a gondolatmenethez.

  Egyébként ez igazából szimpla SQL-kérdés, semmi köze a PHP-hoz, nyugodtan mehetett volna az SQL-kérdés topicba, ott talán többen is látják, azok is, akiket a PHP nem érdekel, de vágják az SQL-t (és követik a topicot). Tulajdonképpen nem tudom, melyik a látogatottabb topic.

• #1992 Jim Tonic nagyúr wolandino #1988

  2012-01-18 15:25:30 #1992

  Ö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

  

  Jim Tonic

  nagyúr

  válasz wolandino #1988 üzenetére

  Első blikkre semmi gond a lekérdezéssel. Én is rossz indexelésre tippelek.

• #1990 Peter Kiss őstag wolandino #1986

  2012-01-02 18:07:34 #1990

  Ö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 wolandino #1986 üzenetére

  Leegyszerűsítve: vinyóról lassabban jönnek az adatok, mint memóriából.

  Szerintem IO igényes a lekérdezésed, kevés/rossz az indexed.

• #1989 Peter Kiss őstag wolandino #1988

  2012-01-02 18:00:36 #1989

  Ö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 wolandino #1988 üzenetére

  A rows azt mutatja, hogy a MySQL szerint hány sort kell megvizsgálni a lekérdezésben, nem azt, hogy mennyit ad vissza.

  Ja, és nem is feltétlenül pontos.

• #1972 DeltaPower addikt wolandino #1971

  2011-12-01 18:40:16 #1972

  Ö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

  

  DeltaPower

  addikt

  válasz wolandino #1971 üzenetére

  Akkor viszont jobban kellene ismerni a szerkezetet ahhoz, hogy optimalizálni lehessen a queryt. Esetleg megpróbálhatod a 150 ezer soros tábla megfelelő sorait előre lekérdezni egy temporary táblába, és a temporaryt joinolni a többivel.

• #1970 DeltaPower addikt wolandino #1969

  2011-12-01 18:30:34 #1970

  Ö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

  

  DeltaPower

  addikt

  válasz wolandino #1969 üzenetére

  Minden kapcsolódó id-t és minden olyan mezőt indexelj le minden táblában, amelyikkel joinolsz vagy ami alapján sorrendezel.
  Továbbá hasznos lehet denormalizálni a táblát olyan módon, hogy a year(date)-t és a month(date)-t kivinni egy külön mezőbe, így ezekre nem kell függvényt futtani ordernél.

Aktív témák