- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Fotók, videók mobillal
- iPhone topik
- Erős specifikáció, kompakt formában
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy S21 FE 5G - utóirat
- Samsung Galaxy S23 Ultra - non plus ultra
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
Új hozzászólás Aktív témák
-
cidalain
veterán
válasz
cidalain
#1974
üzenetére
Az a verzio lesz valoszinuleg, hogy mivel a bejovo adathalmazban nem osszevissza vannak idopontok, es az adatok fejreszeben benne van a kezdo es vegidopont, igy le fogom kerdezni az adatbazisbol elore a start-end idopont kozotti hibas erteku bejegyzeseket.
Ez jo esetben 0 bejegyzest fog tartalmazni, rossz esetben ugye sokat. De a bejovo adathalmaz 80%-ban nem tartalmaz 250-nel tobb adatot, igy az arra az idopontra vonatkoztatott hibas adatok sem lehetnek tobben
A bejovo adatok fajlban vannak soronkent kell feldolgozni, igy tudom csekkolni az elore lekerdezett hibas ertekesek idopontjanal, hogy lett e jo ertek helyette.
Igy ossze tudok allitani egy INSERT IGNORE-t az adatok nagy reszere, es egy REPLACE beszurast azokra amiknel hibat tartalmazott a bazis.Igy egy SELECT lenne csak, egy INSERT IGNORE, es adott esetben egy REPLACE utasitas, ami azert meg vallalhato, a PHP-ban a check sem lesz talan veszes idoben.
A check-et parameterezhetore irom, igy ha nagyon sok adat jonne, vagy valami, akkor ki tudnam kapcsolni.
-
cidalain
veterán
válasz
martonx
#1973
üzenetére
igen ettől félek én is
azt kell mérlegelnem, hogy mi a fontos, a gyorsaság, vagy az alaposság.
simán előfordulhat hogy a beszúrandó adathalmaz csak 100 értéket tartalmaz, így ez esetben az adatbázisból lekérdezés, és elemzés PHP-ban még vállalható idő alatt lemegy. Viszont az is lehet hogy 15000 adat jön be egyszerre, akkor viszont úgy lekérdezni, és elemezgetni, majd válogatni és úgy beszúrni problémás... -
cidalain
veterán
lenne kis szakmai jellegű kérdésem.
legyen egy egyszerű adatbázis:
timestamp | data, ahol timestamp datetime, és data float, timestamp az elsődleges kulcs.
ebbe értékpárokat szúrok be. az érték lehet jó, és lehet rossz. a rossz érték kódja -9999, minden más esetben jó (ez egy tudatosan választott rossz érték, jellemzően -300 nál nincs kisebb jó érték). a rossz értéknek is van információtartalma az időpont miatt, tehát mindenképpen szerepelnie kell.az adatbeszúrás egy bejövő adathalmaz alapján történik, előfordulhat, hogy jön olyan adat is újra, ami már korábban bekerült az adatbázisba. ezért INSERT IGNORE INTO -val tenném a dolgokat az adatbázisba.
ez szuper.ugyanakkor jöhet olyan jó adat is később, aminél az első beszúrásnál hibás érték volt, és ott jelenleg -9999 van az adatbázisba. itt jó lenne ha ez lecserélődne a jó értékre. erre jött a REPLACE INTO ötlet, ami az új adatokat simán beszúrja, a már meglévőket kérdés nélkül update-eli. ezzel viszont az a bajom, hogy egy meglévő jó értéket felül tudja írni ha az új adathalmazban ott rossz érték van.
igazából a kettő kombinációja lenne jó, hogyha van már olyan időpont az adatbázisban, és az értéke jó, akkor hagyjuk, ha nem jó az érték akkor cseréljük. ha nincs még ilyen időpont akkor szúrjuk be, bármilyen érték is tartozik hozzá.
lehetőség szerint, mivel az adatbázis nagyon nagy lesz, nem szeretném előbb lekérni az adathalmazban szereplő időpontokra a bázis aktuális tartalmát, és kiemelezve eldönteni, hogy melyik adatot kell insert-elni/update-elni, hanem csak úgy bezuttyantani, de jó lenne ha replace egy feltétel függvényében futna le.
van lehetőség ilyesmire?
vagy csináljam azt, hogy a bejövő adathalmazt kétfelé veszem?
ha az érték jó, akkor REPLACE INTO
ha az érték rossz, akkor IGNORE INTO
és így ha rossz érték van, akkor csak abban az esetben kerül be, ha ahhoz az időhöz még nem volt semmi? -
#1512
cidalain
veterán
trisztan94
#1511
cidalain
veterán
válasz
trisztan94
#1511
üzenetére
A lekérést így is, úgy is fel kell dolgozni.
Mivel olyan SQL parancs nincs full adatbázis, és tartalom lekérdezésre, ami egyetlen lekérdezéssel tenné ezt, ezért alternatív megoldás kell. Ezt kérted.
Command lineban ha exportálsz, nem egy fájlt kapsz vissza mentés máskénttel. Mivel export minden benne van ami neked kell. Kell rá írnod feldolgozó rutint. -
cidalain
veterán
válasz
martonx
#1508
üzenetére
kivéve ha az a más program az egy adott program. és neki nincs lehetősége migrálni.
(pl könyvelő program, számlázó program, raktáros program - nekem az a tapasztalatom, hogy ugyan adnak ki hozzá folyamatos frissítéseket, de a platformok fejlődését nem minden esetben követik a programok. de az is igaz, hogy ezekhez szokott support is tartozni és rá lehetne kérdezni hogy mi a helyzet)én sem tartanám szerencsésnek több szerver futtatását.
ráadásul ami 5.1-en elfut, annak gond nélkül el kellene futni 5.5-ön is szerintem. -
#1503
cidalain
veterán
Apollo17hu
#1501
cidalain
veterán
válasz
Apollo17hu
#1501
üzenetére
ja valószínűleg az lesz, az átgondolt tábla verzió, még egy kicsit finomítva
egyszerűbb kezelni sokkal, bár több bájt letárolni.
(nekem nem devizacuccokkat kell tárolni, csak ez volt egy nagyon hasonló példa)jelenleg van egy adott tábla formátum, de az egész rendszert újraírom, mert a legutóbbi koncepció már lassan 5 éves, és azóta egy csomó minden változott, és a jelenlegi verziójú adatbázis nem nagyon rugalmas.
és a rugalmasságot viszont csak az "átgondolt" szerkezetű táblával tudom biztosítani.
-
cidalain
veterán
válasz
cidalain
#1498
üzenetére
ha az átgondolt táblát használom akkor egy ilyen egyszerű lekérdezéssel meglennék:
SELECT MAX(date) AS last,type,value FROM `data2`
GROUP BY typeilletve dinamikussá is válna, hisz bármilyen típusú valuta bejöhet később ami most nincs, illetve ki is kerülhet ami már nem kell gond nélkül.
csak rohadtul sok adatom lesz így feleslegesen, attól félek.
-
cidalain
veterán
úgy kell elképzelni a feladatot, hogy például én egy pénzváltót csinálok.
árfolyamokat rögzítek a forinthoz képest.Tábla:
időpont | usd | chf | eur | .............és még sok másik is lehetnebizonyos időközönként valahol a nagyvilágba frissítik az árfolyamokat.
amikor változás van, akkor beszúrok egy időpontot, és azoknál ahol változás volt beszúrom az új árfolyamot.
ahol nem volt változás, ott nem akarok beszúrni semmit.és akkor a lekérdezésnek azt kellene ugye kidobnia, hogy egyes valutáknál melyek a legfrisebb árfolyamok
Az eddigi megoldások korlátosak, és nem igazán idomulnak automatikusan a valuták számának növekedésekornyilván elgondolkodtam egy teljesen másfajta táblaszerkezeten is
idő | valuta típusa | érték -> ahol az idő, és a valuta együtt lenne a PKde ebben az esetben minden időpontnál ahol több valuta is változik annyiszor többször szúródik be ugyanaz az időpont, illetve mindig be kell tennem a valutáknak is az azonosítóját. ettől meg úgy érzem hogy feleslegesen sok anyagot pumpálok az adatbázisba... 100000 adatnál itt már megabájtokat fog jelenteni. és több ilyesmi táblám is lenne még egy adatbázison belül...
-
#1497
cidalain
veterán
Apollo17hu
#1496
cidalain
veterán
válasz
Apollo17hu
#1496
üzenetére
"Ez a kimenet szerintem nem megvalósítható, mert a lastvalue mezőben eltérő adattípusok szerepelnének."
ezt nem értem, mert mindegyik val adat típusa VARCHAR(25).A másik jó, és azt csinálja amit gondolok, csak 6 darab select van benne.
annyiban különbözik ettől, hogy itt 3 result-ot kell feldolgozni, ott meg csak 1-et.SELECT id,val1 FROM sample
WHERE val1 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val2 FROM sample
WHERE val2 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val3 FROM sample
WHERE val3 <> ""
ORDER BY id DESC
LIMIT 1melyik optimálisabb? egy olyan adattáblán lenne használva amiben van 50-100.000 sor!
-
#1494
cidalain
veterán
Apollo17hu
#1493
cidalain
veterán
válasz
Apollo17hu
#1493
üzenetére
igen
-
cidalain
veterán
eddig ezt úgy csináltam hogy lekérdeztem az utolsó egy napnyi adatot, php-ban feldolgoztam mindegyik adatot egy-egy tömbbe, és aztán kivettem mindegyikből az utolsó értéket meg az időt hozzá.
csak nyilván az alábbi problémák fordulhatnak elő:
- ha az utsó egy napban valamelyik adat mégsem kapna értéket, akkor az nem lesz meg
- a sql lekérdezés eredménye mondjuk 1440 sor, melyből nekem tulajdonképpen annyira van szükségem csak ahány adat oszlopom vana másik hogyha mindegyik adathoz külön lekérdezést csinálok, melyeknek 1-1 sor az eredménye
- ekkor viszont annyi lekérdezés van ahány adatmezőezt szeretném optimalizálni, hogy ne legyen felesleges sok adat, amit még utófeldolgozni kell, és ne legyen sok lekérdezés se.
-
cidalain
veterán
válasz
PazsitZ
#1490
üzenetére
nem
Az esetemben a val értékei nem összehasonlíthatóak egymással:
Átírtam a példát amit küldtél
[link]Fontos hogy nem mindegyik időpontban van kitöltve minden érték, vannak üres cellák is.
én a fennti átírt példához a következő kimenetet szeretném látni:
id val1 val2 val3
4 ló - -
3 - 3 -
5 - - 12345tehát mindegyik val-ból a legutolsó ID-jű nem üres értékűt
de inkább valami ilyen kimenet lenne a frankó:
valid id lastvalue
val1 4 ló
val2 3 3
val3 5 12345 -
cidalain
veterán
Sziasztok, kis help kellene
Adott egy tábla:
timestamp (PK) | adat1 | adat2 | adat3 | adat4Sok időpont van benne, de nem mindegyik időpontnál van minden adatsornak értéke, van olyan idő ahol valamelyik adat üresen van. és olyan időpont is van ahol több adat értéke is ki van töltve (olyan időpont nincs ahol mindegyik adat üres)
Olyan lekérdezést kellene készítenem, amely 1 lekérdezéssel visszaadja mindegyik adatsor legutolsó időpontját, és értékét (azaz a legutolsó nem üres értéket).
Azaz jelen példa szerint a lekérdezés eredményének 4 sorosnak kellene lennie (és persze ezek között előfordulhat azonos idő, ha az adatok elosztása pont úgy jön ki)a "SELECT adat1 FROM table ORDER BY timestamp DESC LIMIT 1" nyilván nem jó mert ezzel csak egy adatsor legfrissebb értékét kapom meg. a példában csak 4 adatsort írtam, de valójában persze ez sokkal több...
Köszi
-
cidalain
veterán
válasz
martonx
#1485
üzenetére
már megtaláltuk a hibát, sokat segített az programba épített extra logolás.
tulajdonképpen nem is abban az adatbázisban van a hiba, ahol kerestük, hanem egy másikban - backup, ezért nem értettük a problémát. most kiiktattuk a backupot, és minden oké, majd a hétvégén megvizsgáljuk hogy mi sérült meg a backupban.
-
cidalain
veterán
válasz
martonx
#1483
üzenetére
Az ID-n kívüli másik két mező értéke: timestamp, és egy másik táblára mutató azonosító. Egyik sem egyedi, értékük bármi lehet, lehet egyforma is. A programnál állítottunk be logot, hogyha exception van akkor printelje logfájlba a parancsot aminél bekövetkezett. Sima Insert into parancs, jó szintaxissal, és ide dobta a Duplicate Entry-t a mysql return-ja.
Nekünk is a progi a gyanús, de nem nagyon tudjuk pontosan belőni hogy hol. Most már az is gyanúnk hogy a hiba nem is ez, ez csak a következménye a dolognak.
Lehet a mysql-ben olyat esetleg állítani, hogy naplózza az összes queryt egy usertől?
Ezesetben be tudnánk kapcsolni a program által használt userre egy figyelést, és az összes adatbázisban végzett műveletét tudnánk ellenőrizni, és talán közelebb jutnánk a problémához.(sajnos azért is vagyunk tanácstalanok, mert az alap program már 3 éve működik hiba nélkül, és most meg kijött rajta ez a 3 milliomodik beszúrás után. új adatbázisra irányítva a probléma más 100ezernél jelentkezett, most meg már még hamarabb is ki tudjuk akasztani.)
-
cidalain
veterán
Üdv.
Érdekes problémával találkoztam, és nem jutok dűlőre:
Adott egy MySQL adatbázis, melynek van egy táblája:
-ID
-time
-akármiAz ID int 10 típusú, és auto increment.
Beszúráskor előjött egy olyan hibaüzenet hogy Duplicate Entry, és az ID-re hivatkozott. De hát az ID ugye auto increment!
Legelőször az ID típusát vizsgáltam meg hogy nem e túl kicsi, és elérte az adott adattípushoz tartózó maximális értéket, de nem: Int 10 típusú, azaz bazinagy szám is belefér, ellenben a kiakadás a 176874-ik ID-nél történt.
A beszúrásokat egy progi végzi, így a hiba keletkezése után több másik beszúrást is csinált volna, ami szintén nem sikerült, hasonló okok miatt.
Mintha a MySQL tudná hogy mi az utolsó érték, de nem inkrementálja...
Neten olvastam egy helyen ezt, azt javasolják hogy másoljam le a táblát és akkor megjavul, amiben igazából nem látom az összefüggést (persze olyan dögivel van hogy a 127-esnél akad meg a rendszer, de ott mindig kiderül hogy tinyint volt az ID típusa).
Annyit csináltam, hogy létrehoztam egy új táblát azonos szerkezettel, de üresen, visszaállítva az ID auto incrementjét 1-re, hogy kezdje elölről. A dolog működött is, de csak ideig óráig, ismét előjött a hiba, de sokkal korábban, már párezres ID érték esetén is.
Hallottatok már ilyenről, ha igen, tudjátok mi a megoldás?
Mysql DB verzió: 5.0.45
Új hozzászólás Aktív témák
Hirdetés
- Kingmax 1x2GB DDR3-1333 RAM
- Használt és ÚJ Gamer Monitor Felvásárlás Gyors és Korrekt Ügyintézés!
- Dell Latitude 5495 Full HD IPS Ryzen 5 pro 2500u Radeon Vega Mobile Gfx i5-8350u verő Bp MPL Foxpost
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 55992Ft+ÁFA
- Külföldi csomagszállítás Packeta csomagpontokon keresztül!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest