Hirdetés
-
Huawei Watch Fit 3 - zöldalma
ma Megnéztük, hogy tényleg okosóra lett-e a Huawei fitnesz karperecéből.
-
Hardverek pünkösdre
ph E-book olvasók, komponensek és perifériák kerültek hétvégi összeállításunkba.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
PROHARDVER!
Amit érdemes tudni a Raspberry Pi-kről:
A legelső változat 2012-ben jelent meg. Pici, olcsó és nagyon alacsony fogyasztású, hobby-célú kártyagép. Felépítése ARM alapú, nem PC-architektúra, hanem kb. egy régi mobilhoz hasonló. Nagyon sok mindenre használható! A Linux-nak és a magas eladási mennyiségnek köszönhetően jelentős fejlesztőtáborral rendelkezik.
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz inf3rno #14237 üzenetére
Bocs, de pont így hangzott.
"Azt írtam, hogyha nincs szükség különösebb szűrésre, csak napi és havi szintű kirajzolásra, akkor teljesen megfelel a fájlrendszer is az adatok tárolására, és nem kell adatbázis"
No de ezt írta:
"Kezdésnek mondjuk 3 hónapra visszamenőleg lehetne visszanézni az adatokat. Itt lehetne választani, hogy mekkora időszakot mutasson, pl. beállítani nap és óra szerint, mettől meddig."
Szóval szükség van a különböző szempontok szerinti szűrésre. Innentől kezdve már nem mindegy, hogyan tároljuk az adatokat, mert adott esetben nehezítheti a feldolgozást."Ha időközben változnak az igények, akkor meg fájlokból bármikor fel lehet tölteni az adatokat egy adatbázisba. Mi ebben a rugalmatlan?"
Az, hogy beleteszünk még egy nagy lépcsőt a dologba, van egy pluszmunka, egy utófeldolgozási igény, amikor eleve feltölthetnénk normális "nyilvántartásba" is az adatokat. Ráadásul már a kezdetektől ez az igény. A vesszővel elválasztott fájl rugalmatlansága meg adott: az egyes "oszlopokban" tárolt adatoknál figyelni kell az elválasztó karakterre, az "oszlopok" sorrendje kötött, a struktúra változása egy fokkal nagyobb kényelmetlenséget jelent talán, mint az adatbázisbeli nyilvántartás esetén (persze ez nem feltétlenül igaz, esetfüggő, attól függ, mekkora a változás, adatbázisnál is melós lehet). Amennyiben az általad javasolt megoldást választja, akkor az utófeldolgozás során bizonyos időközönként egy külön scripttel még ezeken a vesszővel elválasztott adatokon végig kell menni, kihámozni belőle a lényeget, feltölteni egy másik adatbázisba, amit aztán a weboldal scriptje olvasgat. Olvashatná egy helyről is - persze ha nem ugyanez a "gép" a webszerver is, akkor meg a legjobb lenne, ha egy fizikailag másik gépen lévő adatbázisba töltögetné fel az adatokat."Szvsz inkább az igénytelen, ha valaki nem gondolja végig a problémát, és ágyuval verébre lő."
Ez szerintem pont nem az ágyú és a veréb esete, legalábbis az alapján, amik a felvázolt igények. Persze tök szubjektív az egész, rengeteg megoldás létezik rá, inkább a saját elképzeléseimet vázolom fel, hogy én próbálnám eleve rugalmasabban kezelhető adatstruktúrában eltárolni (és persze az én megoldásomnak is lehetnek hátrányai).
De mondjuk ezt a srácnak kell eldönteni, hogy melyik megoldást választja, mi most csak beszélgetünk a potenciális megvalósításokról.Sk8erPeter
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs