- Samsung Galaxy Watch6 Classic - tekerd!
- Milyen okostelefont vegyek?
- Honor 200 Pro - mobilportré
- iPhone topik
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy Watch7 - kötelező kör
- Mobil flották
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Google Pixel 9 Pro XL - hét szűk esztendő
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Új hozzászólás Aktív témák
-
#7800
Sk8erPeter
nagyúr
cucka
#7799
Sk8erPeter
nagyúr
"Kivéve ha automatizálni szeretnéd a form feldolgozását."
Na de ez még mindig nem mond ellent annak, amit írtam. Automatizáltan is ugyanúgy benne lehet az isset() VAGY !empty() ellenőrzés...A felhasználótól érkező információ megbízhatatlanságáról meg szerintem nem kell különösképpen tárgyalnunk, ez evidens...
Nyilván kliensoldali ellenőrzés sehol nem vált ki semmiféle szerveroldali ellenőrzést, ezt mindketten tudjuk, nem is tartozik szorosan a témához.
Arról beszéltem, hogy az isset ellenőrzés azért sem hülyeség, mert kliensoldalon kiszedhet a formból a júzer elemeket, úgy postolja el, Te meg mondjuk ha nem nyomatsz egy isset() ellenőrzést, akkor lehet, hogy vizsgálod a POST tömb olyan indexét, ami nem is létezik, így kaphatsz egy notice-t.A JavaScript hiányával egyetértek, hogy manapság már nem érdemes foglalkozni, legfeljebb szerveroldali validálás szintjén. Mégsem értek egyet feltétlenül a checkbox hidden mezővel való kiegészítésének szükségességével, ez a lényeg.
-
#7799
cucka
addikt
Sk8erPeter
#7797
cucka
addikt
válasz
Sk8erPeter
#7797
üzenetére
De a többi elpostolt értékhez tartozó alkalmazáslogikába beletenni egy isset() vagy !empty() (ez úgyis lefedi az isset-et) ellenőrzést nem kerül semmibe.
Kivéve ha automatizálni szeretnéd a form feldolgozását.Ez az ellenőrzés úgysem árt, pl. mi van, ha valaki elpostol úgy adatokat, hogy belegányol a kódba kliensoldalon, kiszed elemeket belőle, Te meg a nem létező elemekre futtatsz mondjuk további vizsgálatokat
A checkboxos-javascriptes trükk nem váltja ki az adatok szerveroldali ellenőrzését. A felhasználó által küldött információ mindig megbízhatatlan, ez független attól, hogy az az információ egy egyszerű form elemből jön, vagy közbeiktattunk valamilyen javascript kódot is. (Tehát teljesen mindegy, hogy javascript-el rakod össze az űrlap adatait vagy sem)Én is úgy vagyok vele manapság, hogy k@pja be, aki kikapcsolja a böngészőjében manapság a JavaScriptet, de azért még mindig gondolni kell erre az esetre is.
A munkahelyemen mi nem támogatjuk sem az IE6-ot, sem pedig az ilyen klienseket, ahol nincs javascript.
Szép lassan 2012 van, valahol meg kell húzni a határt - az egész web a javascript-ben írt böngészőben futható alkalmazásokról szól. Nem lehet egyszerre megfelelni a modern kor igényeinek és támogatni az elavult klienseket. -
#7798
Sk8erPeter
nagyúr
meone
#7796
Sk8erPeter
nagyúr
Hű, már nagyon kezded összekutyulni, most már az index.php-be is beletetted ezt, aminek a JSON-generáló fájlban kéne lennie?
Mé', minek?
Korábban ezt írtad: "Ha magát a fájlt linkelem be direktbe nem feldolgozva a PHP által akkor azt se olvassa be." Először azt oldd meg, hogy saját tartalmat mindenféle generálás nélkül egyszerűen kiíratsz, a megfelelő formátumban.
Kezdd azzal, hogy simán a cucc.php fájlodba másold bele ennek a fájlnak a tartalmát (persze először kommentezd ki átmenetileg a saját megírt kódodat), és próbáld ki, úgy működik-e. Ha nem, akkor már eleve itt van valami gáz! Először ezt szűrd ki. Lehet, hogy elérési útvonal, vagy bármi más, de mindenképp figyeld a böngészőben a developer tool konzolját (pl. Chrome-ban F12, FF-ban ugyanez, ha telepítve van a Firebug, esetleg Ctrl+Shift+I Operában Dragonfly-hoz), hogy kiír-e valami hibaüzenetet! (pl. 404, vagy bármi más hiba, JS-exception, stb.)Még annyit esetleg kipróbálhatnál (bár kétlem, hogy ez önmagában megoldja, de ki tudja manapság
), hogy az adatgeneráló PHP-fájlod (nálad cucc.php) elején kiküldesz egy JSON-headert:
header('Content-type: application/json');Ja, még egy, hogy ugye nem tartalmaz BOM-ot az UTF-8-fájlod (ha UTF-8-kódolású egyáltalán)? (Notepad++-ban ezt meg tudod nézni.)
-
#7797
Sk8erPeter
nagyúr
cucka
#7795
Sk8erPeter
nagyúr
Há' vágom én.
De a többi elpostolt értékhez tartozó alkalmazáslogikába beletenni egy isset() vagy !empty() (ez úgyis lefedi az isset-et) ellenőrzést nem kerül semmibe. Ez az ellenőrzés úgysem árt, pl. mi van, ha valaki elpostol úgy adatokat, hogy belegányol a kódba kliensoldalon, kiszed elemeket belőle, Te meg a nem létező elemekre futtatsz mondjuk további vizsgálatokat - ezzel legalább az ilyen rosszindulatú szándék elé is teszel plusz egy szűrőt. (Félre ne érts, itt nem azt mondom, hogy ezzel kivédsz bármilyen támadást, vagy hasonló, de legalább plusz egy lépés afelé, hogy teljes körű ellenőrzésed legyen.)
Én is úgy vagyok vele manapság, hogy k@pja be, aki kikapcsolja a böngészőjében manapság a JavaScriptet, de azért még mindig gondolni kell erre az esetre is. -
#7796
meone
tag
Sk8erPeter
#7794
meone
tag
válasz
Sk8erPeter
#7794
üzenetére
Bocsi, valahogy elkerülte a figyelmemet.
Megcsináltam a változtatásokat de akkor sem működik.
Most így néz ki az index.php: [link]
Viszont, ha a cucc.php-ba beleteszem a zárójeleket és a pontosvesszőt akkor nem jelenik meg a diagram az index.php oldalon. -
#7795
cucka
addikt
Sk8erPeter
#7794
cucka
addikt
válasz
Sk8erPeter
#7794
üzenetére
Minek hidden mező és JS ehhez?
Azért, mert így a szerver oldalon fel tudod dolgozni az értékét ugyanazzal a kóddal/alkalmazáslogikával, mint amivel a többi elpost-olt értéket is feldolgozod.Vágod, ha van egy x űrlapelemed, akkor minden esetben tudni fogod, hogy az ő értéke a $_POST['x']-ben található. A hidden mezős technika célja, hogy ez így checkbox-okra is működjön.
-
#7794
Sk8erPeter
nagyúr
cucka
#7788
Sk8erPeter
nagyúr
Minek hidden mező és JS ehhez?
Miért nem elég, ha csekkoljuk isset()-tel, hogy megvan-e egyáltalán a checkbox típusú input (name szerint)?===
(#7789) meone:
"amit belinkeltél abban vannak kommentek nálam meg nincsenek. Ennyi a külöNbség."
... meg amit már mondtam párszor... A zárójeleket és a pontosvesszős lezárást még mindig lehagytad... -
#7793
Speeedfire
félisten
Speeedfire
félisten
Köszi mindkettőtök segítségét.
-
#7792
cucka
addikt
Speeedfire
#7790
cucka
addikt
válasz
Speeedfire
#7790
üzenetére
Nos ezt meglehet oldani dinamikusan valahogy vagy minden egyes ilyen esetben fel kellene darabolnom a tervrajzot, majd egyesével ezeket kitölteni?
Utóbbi.Illetve, mennyit nem pofátlanság egy ilyen oldalért kérni?
- Fogod azt az órabért, amivel kiegyezel és nem érzed azt, hogy szarért-hugyért dolgozol.
- Megsaccolod, kb. hány óra alatt leszel vele kész. Próbálj nagyvonalúan saccolni, főleg, ha olyan dolgot kell fejleszteni, aminek még neked is utána kell nézned.
- Meghatározod a projekt szopófaktorát. Ez azért fontos, mert mindig lesznek váratlan kérések, apró javítások, stb., amivel nem tudsz előre kalkulálni. Javaslat: ha nem különösebben rázós az ügyfél/projekt, akkor kiindulásnak a 2-es szopófaktor kb. jó lesz.Namost a fenti 3 számot összeszorzod és megvan, mennyi az az összeg, amiért neked várhatóan megéri bevállalni a munkát. Ha ennél lényegesen kevesebbet szeretne fizetni az ügyfél, akkor valószínűleg jobban jársz, ha nem vállalod be a munkát.
A kalkuláció általában érvényes mindenféle kis léptékű számtech projektre. Nyilván ha a saját munkádon túl plusz költségeid is lesznek (utazni kell, domain regisztráció, bármi), azt is szépen hozzá kell adni.
-
#7791
Alukard
senior tag
Speeedfire
#7790
Alukard
senior tag
válasz
Speeedfire
#7790
üzenetére
Legjobb tudomásom szerint ezek mind egyedi fejlesztések, de rosszabbnak látszik mint amilyen... Viszont a szint darabolós képeket neked kell megcsinálni.
-
#7790
Speeedfire
félisten
Speeedfire
félisten
Na, kicsit kemény fába fogom vágni azt a bizonyos fejszét lehetséges....
Ma voltam egy leendő ügyfélnél (ingatlanközvetítő, kölcsönző) és olyan oldal kellene nekik, ahol az adott épületnek a tervrajzát fel lehetne darabolni mondjuk emeletenként és az adott emeleteken mutatná a helységeket, hogy xyz helység mekkora, kivan-e már adva vagy sem.
Nos ezt meglehet oldani dinamikusan valahogy vagy minden egyes ilyen esetben fel kellene darabolnom a tervrajzot, majd egyesével ezeket kitölteni?
Ez csak egy része lenne az oldalnak...Ilyesmi kellene nekik. -> [link] virtuális kereső, majd egy adott épületen belül valamelyik emelet...
Egyelőre csak manuálisan tudom ezt elképzelni.Illetve, mennyit nem pofátlanság egy ilyen oldalért kérni?
-
#7789
meone
tag
Sk8erPeter
#7784
meone
tag
válasz
Sk8erPeter
#7784
üzenetére
A majdnemet arra értettem, hogy amit belinkeltél abban vannak kommentek nálam meg nincsenek. Ennyi a külömbség.
A lekérdezés végeredménye így néz ki:[[1314347520000,30.8],
[1314348120000,30.1],
[1314348720000,31.2],
[1314349320000,31.5],
[1314362520000,35.3],
.....
.....
[1314364320000,35.6],
[1314364920000,35.5]]Feltettem a módosított cuccokat pastebinre:
A módosított index.php: [link]
A cucc.php amiben lekérem az adatokat a MySQL-ből: [link]
A cucc.php ban szereplő kódot szeretném valahogy bele indegrálni az index.php-ba, de ha beleteszem és át állítom hogy onnan szedje akkor eltűnik a diagram. -
cucka
addikt
Checkbox-okat úgy szoktunk feldolgozni, hogy mindegyik mellett van egy hidden mező, ami a checkbox állapotától függően 0 vagy 1 értéket vesz fel. Nyilván ez esetben kell egy javascript kód is, ami a checkbox értékének változásánál frissíti a hidden mező értékét. Ezt a javascript kódot javaslom, kösd rá a checkbox onclick eseményére.
-
Felteszem a kérdést még egyszer, nem jutok vele dűlőre. Szóval ez egy ilyen összetett lekérdezés / update lenne egy oldalon. Lényegében a weboldal alap beállításait szeretném módosítani. Van pár elem ami input, van pár ami textbox és van pár ami checkbox.
Na most ha nem kap a checkboxom értéket - nincsen kipipálva - akkor elpostoláskor "üres" lesz és arra kéne egy megoldás. De ha jól sejtem akkor marad a következő, hogy megnézem üres -e. Ez azért nem jó nekem sajnos mert egyszerre három táblába is dolgozok, remélem van rá valami egyszerű megoldás.
Másik, hogy megint a newhostingnál miért nem megy a mod_rewrite
Valaki aki ott van, tudna egy működő .htaccess fájlt nekem mutatni? Szerintem valami egyszerű sort kihagytam.
-
#7786
mobal
nagyúr
Sk8erPeter
#7785
válasz
Sk8erPeter
#7785
üzenetére
Szerintem próbáltam kérdezés előtt
, de reméltem van valami egyszerűbb módszer is. Akkor marad ez.
-
#7784
Sk8erPeter
nagyúr
meone
#7781
Sk8erPeter
nagyúr
"a fájlom nekem is úgy épül fel majdnem teljesen mint a belinkelt"
Hát ne MAJDNEM teljesen úgy épüljön fel. Egyezzen meg szintaktikájában. Mibe telne kiegészíteni azzal,ami még hiányzik? (pl. hiányzó zárójel, lezárás)
Simán lehet, hogy valami van még, ami nem tűnik fel. Nem tudnál jsfiddle-re vagy máshova felrakni egy példakódot, azzal a konkrét legenerált tartalommal, ami a tiéd?
Mondjuk az oldalon, amit linkeltél, szerepelt egy jsFiddle-link: [link].(#7782) biker: hmm, hát ez tanulságos. És akkor hogy oldod meg ilyen esetekre a kérdést?
-
#7782
biker
nagyúr
Sk8erPeter
#7777
biker
nagyúr
válasz
Sk8erPeter
#7777
üzenetére
zip-elt válasz: 4 sor volt a táblában, és ezen futtattam a FTS-et, és ha egy találat az összes rekord 50%-át kiteszi, akkor is ha nem stopword, annak tekinti a rendszer, így az FTS 0 sort ad vissza
-
#7781
meone
tag
Sk8erPeter
#7780
meone
tag
válasz
Sk8erPeter
#7780
üzenetére
Ha magát a fájlt linkelem be direktbe nem feldolgozva a PHP által akkor azt se olvassa be.
Csak akkor jelenik meg ha külön fájlból olvassa be.
Maga a fájlom nekem is úgy épül fel majdnem teljesen mint a belinkelt.
Egyedül az elején nincsen kérdőjel.
Nem lehet az, hogy valamit az ajax mahinál még? -
#7780
Sk8erPeter
nagyúr
meone
#7779
Sk8erPeter
nagyúr
Mondjuk annyi különbség tűnt fel, hogy a linkelt JSON-fájlban úgy van meg a tartalom, hogy ezek zárójelek közé vannak ékelve (meg kérdőjel az elején):
?( // itt kezdődik...
[ // ez már a tiéd
[1314347520000, 30.8],
[1314348120000, 30.1],
......................
]
);Nem tudom, ez okoz-e igazán releváns különbséget, de nem tartom elképzelhetetlennek...
Ha a belinkelt fájlt teszed be a getJSON-be a sajátod helyett, akkor azzal működik? -
#7779
meone
tag
Sk8erPeter
#7778
meone
tag
válasz
Sk8erPeter
#7778
üzenetére
Az a baj, hogy ugyan ezeket kapom és mégse dolgozza fel, íme egy részlet ami kinyom a php:
[[1314347520000,30.8],[1314348120000,30.1],[1314348720000,31.2],[1314349320000,31.5],[1314349920000,31.7],[1314350520000,32.5],[1314351120000,33.2],[1314351720000,33.7],[1314352320000,34.3],[1314352920000,34.6],[1314353520000,34.7],[1314354120000,35.1],[1314354720000,35.2],[1314355320000,34.7],[1314355920000,34.3],[1314356520000,34.6],[1314357120000,34.5],[1314357720000,34.5],[1314358320000,34.6],[1314358920000,34.8],[1314359520000,34.9],[1314360120000,35],[1314360720000,35.2],[1314361320000,35.4],[1314361920000,35.4],[1314362520000,35.3],[1314363120000,35.4],[1314363720000,35.4],[1314364320000,35.6],[1314364920000,35.5]]
Limitáltam, hogy csak 30 sort szedjen ki így könnyen látható minden ugyan az mint amit te belinkeltél.
A hivatkozás, meg csak ideiglenes, általában én is úgy szoktam, tudom nagy szívás van abból ha kötött az útvonal. -
#7778
Sk8erPeter
nagyúr
meone
#7776
Sk8erPeter
nagyúr
Valószínűleg helytelen a formátuma a JSON-nek, amit kinyomsz, ezért nem tudja feldolgozni, és úgy tűnik, nincs megoldva a rendes hibakezelés, hogy egyértelmű legyen a hiba oka.
Itt a példa JSON-fájl: [link], ilyesmit kellene kiíratnod.
Rakd fel mondjuk pastebinre, hogy Te mit kapsz, milyen formátumú lesz az általad kiíratott $out változó kimenete, hátha abban megtaláljuk a hibát.
--
Még egy gyors megjegyzés:
echo "http://localhost/megj/Hs/examples/basic-line/cucc.php";
Soha ne használj ilyen szinten kötött címeket!! Mi van, ha már költözteted egy éles szerverre a cuccaidat, akkor mindenhol majd szépen kicserélgeted a "http://localhost" címet? Nagyon kényelmetlen megoldás. Ne legyen benne a domain, se a protokoll (http/https). Ez nyugodtan lehetne pl. simán "/megj/Hs/examples/basic-line/cucc.php" (a localhostos rész nélkül), ha már - localhoston - szerverről futtatod. -
meone
tag
Sziasztok.
Egy kicsit meg akadtam egy feladat megoldása közben.
A helyzet a következő.
Van egy olyan vonaldiagramom amit ajax segítségével dolgozok fel.
Az alap diagram innen való ezt módosítani szeretném illetve módosítottam már.
[link]
A legelső amit éppen módosítok.A problémám ezzel az, hogy az adatokat egy külön JSON fájlból szedi, ezt már kiváltottam, úgy, hogy egy PHP fájlban megtörténik az adatok feldolgozása MySQL-es adatbázisból.
A megjelenítéskor mikor pórbálom beletenni a kódba az általam kreált kódot a diagram eltűnik viszont ha ugyan ezt a kérés kiteszem a egy fájlba és azt hivatkozom be akkor megjeleníti.
A kód ami gondot okoz az ez:<script type="text/javascript">
$(function() {
$.getJSON('<?php
echo "http://localhost/megj/Hs/examples/basic-line/cucc.php";
?>',
function(data)
{
// Create the chart
window.chart = new Highcharts.StockChart({
chart : {
renderTo : 'container'
},
rangeSelector : {
selected : 1
},
title : {
text : 'Idojarasi adatok'
},
xAxis : {
maxZoom : 1 * 24 * 3600000
},
series : [{
name : 'ch',
data : data,
tooltip: {
yDecimals: 2
}
}]
});
});
});
</script>Valami ötlet esetleg, hogy hogyan módosítsam a kódot, hogy ne egy fájlból szedje az adatokat, hanem az általam készített lekérdezést hajtsa végre?
Ezzel a kóddal próbálom össze hozni a dolgot:
$res = "SELECT unix_timestamp(concat(`;yr`,'-',`mo`,'-',`dy`,' ',`hr`,':',`mi`,':00'))*1000 as datum,`T1` FROM `alm1` ";
if ($eredmeny = mysql_query($res)) {
$sorok_szama=mysql_num_rows($eredmeny);
$mezok_szama=mysql_num_fields($eredmeny);
//,MYSQL_ASSOC
$out = "[";
while ($sor = mysql_fetch_array($eredmeny,MYSQL_ASSOC)) {
$out .= "[{$sor['datum']},{$sor['T1']}],";
#$sorm = json_encode($sor2);
}
$out = substr($out,0,-1)."]";
echo $out;
} else {
echo mysql_error();
}Köszi előre is.
-
#7775
biker
nagyúr
Sk8erPeter
#7720
biker
nagyúr
válasz
Sk8erPeter
#7720
üzenetére
ó, mondhatni shitfuck
Tudod,mi volt a baj? 4 soros tábla volt a tesztalany.
és ekkor ez a bibi:The search result is empty because the word “MySQL” is present in at least 50% of the rows. As such, it is effectively treated as a stopword. For large data sets, this is the most desirable behavior: A natural language query should not return every second row from a 1GB table. For small data sets, it may be less desirable.
A word that matches half of the rows in a table is less likely to locate relevant documents. In fact, it most likely finds plenty of irrelevant documents. We all know this happens far too often when we are trying to find something on the Internet with a search engine. It is with this reasoning that rows containing the word are assigned a low semantic value for the particular data set in which they occur. A given word may reach the 50% threshold in one data set but not another.
The 50% threshold has a significant implication when you first try full-text searching to see how it works: If you create a table and insert only one or two rows of text into it, every word in the text occurs in at least 50% of the rows. As a result, no search returns any results. Be sure to insert at least three rows, and preferably many more. Users who need to bypass the 50% limitation can use the boolean search mode; see Section 11.9.2, “Boolean Full-Text Searches”.
Bármire kerestem, 2-ször vagy többször szerepelt
-
wolandino
tag
válasz
Sk8erPeter
#7773
üzenetére
nem az exportálás, hanem maga a lekérdezés ne legyen több.
de min1 is, a lényegi választ már megkaptam, még1x köszönöm -
#7773
Sk8erPeter
nagyúr
wolandino
#7769
Sk8erPeter
nagyúr
válasz
wolandino
#7769
üzenetére
"ezért nem akartam betenni, mert ha kiszedem az ordert úgy ahogy van, akkor se sokkal jobb a helyzet, 15 mp körüli."
Ezek szerint nem jött át, mire jó az EXPLAIN... Azért akartuk látni, mert hátha ott MEGMAGYARÁZZA, hogy mi is az oka, hogy ilyen lassú fostalicska..."és nem szeretnék olyan lekérdezést tenni az alkalmazásba, ami több mint fél másodperc, mert engem már nagyon szokott idegesíteni, amikor többet kell várni."
Hát vazze, miért, szerinted az a normális, hogy max. fél másodperc legyen egy 150 ezres agyonrendezgetett adatmennyiség fájlba (???? ezt sem írtad) exportálása? Komoly adatbázisszervereknél simán, de az nem kevés teljesítményre képes akkor. 15 mp tényleg sok, ezen lehet faragni. De nehogy már napi probléma legyen (vagy ha az, fusson időzítve), és bárki pampogjon egy kicsit több idő miatt, pár másodpercet tud várni, amikor nem kis adatmennyiség kiírásáról van szó...Mellesleg nem értelek, segítséget kérsz, akkor miért kell ennyire fukarkodni az infókkal. Gondolhatod, hogy nem ebből fogunk itt meggazdagodni, hogy beraksz egy komplett screenshotot az explainről... meg különösebben senkit nem érdekelnek az adataid, csak segíteni szeretnénk megoldani a problémádat.
-
#7771
rt06
veterán
DeltaPower
#7768
rt06
veterán
válasz
DeltaPower
#7768
üzenetére
az order ertheto, ev-honap alapjan akar rendezni, azon belul pedig nev alapjan
attol pedig, hogy nem a vegen, hanem az elejen csinalja meg a 300000 datumkonverziot, nem lesz gyorsabbakkor mar jobb megoldas, kulon eltarolni az evet es a honapot (a leheto legkisebb egesz tipussal, esetleg enum-mal), majd azok alapjan szurni
igaz, hogy az adattarolas szempontjabol nem a legszebb megoldas, de a sebesseget nagysagrendeket fog dobni -
wolandino
tag
válasz
DeltaPower
#7768
üzenetére
-
wolandino
tag
válasz
DeltaPower
#7768
üzenetére
egyszerűség.
ezért nem akartam betenni, mert ha kiszedem az ordert úgy ahogy van, akkor se sokkal jobb a helyzet, 15 mp körüli.
és nem szeretnék olyan lekérdezést tenni az alkalmazásba, ami több mint fél másodperc, mert engem már nagyon szokott idegesíteni, amikor többet kell várni. -
#7768
DeltaPower
addikt
cucka
#7767
DeltaPower
addikt
Ezt az order-t én se értettem. Azt sem, hogy ha mindenképp year és month kell, akkor miért nem
select ..., year(1.date) as 1year ... order by 1year, ...
formában, szerintem gyorsabb mintha ordernél futtatná a dátumfüggvényeket.
Másik: SELECT *-ot csak az egyszerűség kedvéért van így, vagy tényleg minden mezőt lekérdez? -
cucka
addikt
válasz
wolandino
#7765
üzenetére
Például ez a részed elég szar:
ORDER BY year(1.date), month(1.date), 2.name
Itt ugye a year meg a month függvény az eredmény összes sorára le fog futni, az eredménye tárolódni fog majd utána 150k értéket még rendezni is kell.
Rendezhetnéd 1.date szerint, az gyorsabb.Az explain eredményét még mindig nem láttuk. Fosol, hogy ellopjuk a táblaneveidet, vagy mi van?
-
wolandino
tag
válasz
Sk8erPeter
#7759
üzenetére
az explain tudtommal sszépen végigmegy táblánként
lekérdezi a 150k-st, vissza ad 150 k-t, majd megy a többire, azok meg 1-eket, az egyik 5-öt.
Az indexek rendben vannak.
Az id-k azok, illetve a 150k-s táblának szinte minden attribútuma, azok közül az összes, ami id-t tartamal, ezekre megy a JOIN.SELECT *
FROM (1)
JOIN 2 ON 1.d = 2.id
JOIN 3 ON 1.d = 3.id
JOIN 4 ON 1.d = 4.id
JOIN 5 ON 1.d = 5.id
JOIN 6 ON 1.d = 6.id
JOIN 7 ON 1.d = 7.id
JOIN 8 ON 1.d = 8.id
JOIN 9 ON 1.d = 9.id
JOIN 10 ON 1.d = 10.id
JOIN 11 ON 1.d = 11.id
JOIN 12 ON 1.d = 12.id
JOIN 13 ON 1.d = 13.id
JOIN 14 ON 1.d = 14.id
ORDER BY year(1.date), month(1.date), 2.nameazért nem írok az alkalmazásról részletet, mert kompromisszumos megoldásokkal csak akkor szeretnék foglalkozni, ha kiderül, hogy AB szinten nem lehet gyorsítani. Igazából a lekérdezés része érdekel. Ha valakinek jobb úgy, fogja fel teoretikus kérdésnek
Akkor mondom majd a felhasználónak, hogy akkor legyen így és így.... amíg nincs így, addig megpróbálom megvalósítani az elképzelését. -
#7764
Speeedfire
félisten
Sk8erPeter
#7763
Speeedfire
félisten
válasz
Sk8erPeter
#7763
üzenetére
Ezek a top-ok csak seo miatt születnek.
-
#7763
Sk8erPeter
nagyúr
Speeedfire
#7762
Sk8erPeter
nagyúr
válasz
Speeedfire
#7762
üzenetére
Kivételesen ebben tényleg találtam említésre méltó tippeket, pedig nagyon sokszor haszontalanok ezek a "100 tipp arról, hogyan tudsz minél több időt elkúrni ennek a cikknek az elolvasásával"-jellegű rovatok.
-
#7762
Speeedfire
félisten
Sk8erPeter
#7759
Speeedfire
félisten
válasz
Sk8erPeter
#7759
üzenetére
Pedig ezt már egyszer linkelted is nekem, de csak felületesen futottam át rajta.
-
#7759
Sk8erPeter
nagyúr
wolandino
#7745
Sk8erPeter
nagyúr
válasz
wolandino
#7745
üzenetére
"explaint is nyomtam:
150k-s tábla 150k lekérdezést ad"
És ez önmagában miért lenne bizonyíték arra, hogy jók az indexek?
Nem értem a logikát."Az indexek rendben vannak."
Ezt honnan veszed? Esélyes, hogy mégsincsenek rendben, azért lassú a query.A többire: ha rejtélyeskedsz, és a lehető legkevesebb infót adod arról, hogy mi, miért, hogyan van megoldva, akkor nem fogunk tudni segíteni... lehetőleg ne tőmondatokban válaszolj, hanem írj le mindent részletesen, akkor érdemi segítséget is tudunk adni.
Pl. hadd lássunk már legalább részletet a query-ből (pastebinre fel tudod nyomni), meg elárulhatnád, milyen mezőid vannak, mi szerint indexeltél.Egyébként az exportálás nem időzítve, cronnal történik? Hanem egy felhasználói felületen?
Mert ha ilyen szinten sok adat van, és úgyis csak exportálás céljára használod, akkor a felhasználó ne sírjon, ha 150k adatra többet kell várnia... Nyilván nem félnaponta exportálgatod az adatokat.
A "chart" alatt itt most mit értesz? Egy Excel-fájlt? Legalábbis remélhetőleg nem egy felhasználói felületen megjelenő valamit...===
(#7747) Speeedfire : Itt is ír az EXPLAIN-ről és sok hasznos trükkről: [link] (azért linkelem megint ezt a cikket, mert kivételesen nem egy terjengős, felesleges idióta tippekkel teli cikkről van szó...)
-
#7755
rt06
veterán
Speeedfire
#7753
rt06
veterán
válasz
Speeedfire
#7753
üzenetére
mer' mondjuk exportalni akar (ugyfeltorzset, cikktorzset, arlistat, akarmit), mondjuk csv-be
-
#7750
rt06
veterán
Speeedfire
#7749
rt06
veterán
válasz
Speeedfire
#7749
üzenetére
jah, igen, ez kimaradt (de lenyegeben annyi csak, hogy a lekerdezes ele teszel egy explain kulcsszot, vagy explain extended kulscszopart
-
#7748
rt06
veterán
Speeedfire
#7747
rt06
veterán
válasz
Speeedfire
#7747
üzenetére
elmeseli, hogyan rakja ossze az adatbazisszerver a lekerest, mikent join-ol, milyen kulcsokat hasznal, milyen sorrendben...
-
wolandino
tag
válasz mindenkinek:
Az indexek rendben vannak.
Szükségem lenne az összes sorra.
explaint is nyomtam:
150k-s tábla 150k lekérdezést ad
a többi 1-et.A kérdés annak is szól, hogy ez egy komoly szerver alatt is így fog-e nyögni, illetve normális-e, hogy eddig tart? mert nekem a 150 k nem tűnik olyan soknak.
Valahogy nem lehet meggyorsítani, ha teszem azt több hardware erőforrást adok a mysql-nek? -
Coyot
őstag
-
wolandino
tag
SQL téma, de hátha tud valaki rá választ adni
Van egy lekérdezésem, amiben 14 táblát joinolok össze, amiből az egyik 150.000 a többi meg 10-100 sort tartalmaz. A 150 k-s táblám tartalmazza a felhasználó bejegyzéseit, az összes többi, csak arra kell, hogy megadjam az id-khez az értéküket. tehát a lekérdezés 150.000 sort ad vissza. A végén van egy order by is year(date), month(fdate), username alapján.
Kb. 22 másodpercig tart a lekérdezés a phpmyadmin szerint. Ha az order by-t kiszedem, valamivel kevesebb. Ez normális, hogy ilyen sokáig tart? Hogyan tudnék rajta gyorsítani, akár mysql beállítással akár úgy, hogy átírom a lekérdezést?
150.000 sor szerintem nem annyira sok egy adatbáziskezelőnek, mi lesz itt milliós nagyságrendnél?
Köszönettel,
W.UI: Az indexek rendben vannak
-
#7740
daninet
veterán
Peter Kiss
#7739
daninet
veterán
válasz
Peter Kiss
#7739
üzenetére
azért mondom h nem értek hozzá, már az elején kilövöm a felelősséget
kösz a választ
-
daninet
veterán
Üdv!
Csak érdeklődés szintjén kérdeznék, nem vagyok témában jártas teljesen
Minap láttam egy flash alapú oldalt, ahol a háttér más sebességgel gördült mint ami előtte van, ettől olyan hatása lett az egésznek mintha a tartalom lebegne a háttér előtt, teljesen élővé tette a dolgot.
Megoldható ez flash nélkül php alapú oldalaknál? -
#7736
mobal
nagyúr
Speeedfire
#7733
válasz
Speeedfire
#7733
üzenetére
Ha jól emlékszem az.
-
Cheesy
őstag
Egyelőre tökéletesnek tűnik, köszönöm.
Viszont segítsetek már egy pöttyet tégyszi, mivel még küzdök a kezdeti tudásbeli hiányosságok nagy részével.Hogyan tudok hivatkozni egy másik meghajtón lévő könyvtárra?
Azaz:jelenleg - E:\xampp\htdocs\aexp\ itt található a script
viszont a fileok mappája már jó lenne ha itt lenne - F:\shared\Létezik erre megoldás?
(Azért kell, mert minden érzékenyebb adat truecrypt volumeban van, és az nem olyan nagy, hogy értelme legyen azt használni megosztásra) -
-
Cheesy
őstag
Ömm... jobban szeretném saját táron tudni a dolgokat, nem minden esetben látom egészségesnek mindenféle nyilvános tárra történő feltöltését az anyagoknak. De ezt utdjuk be az én hülyeségemnek
Van ftp server a vpsen, de attól idegenkednek, nem ismerik, mert nem is szokták használni... így egy Speedfire által belinkelt mappalistázó jó ötlet volna.
Még jobb lenne, ha multiuseres bejelentkezős, mindenki saját mappájába feltöltős nyalánkság lenne, de abból jól működőt még nem találtam. -
#7729
mobal
nagyúr
Speeedfire
#7728
válasz
Speeedfire
#7728
üzenetére
Windows VPS -> Torrentbox?
-
#7727
mobal
nagyúr
Speeedfire
#7726
válasz
Speeedfire
#7726
üzenetére
"Fősulin szakdogakészítés aktuális és a csoporttal elhatároztuk, hogy ha létezne rá mód, megosztanánk egymással amink van. Tervek, doksik, képek,stb."
Nem látok itt scriptet. Dropbox.
-
#7725
mobal
nagyúr
Speeedfire
#7724
válasz
Speeedfire
#7724
üzenetére
Dropbox. Minek ha már van?
-
Cheesy
őstag
A következő a helyzet:
Fősulin szakdogakészítés aktuális és a csoporttal elhatároztuk, hogy ha létezne rá mód, megosztanánk egymással amink van. Tervek, doksik, képek,stb.
Nekem van egy win-es (nem röhög! ) vpsem, gondoltam használhatnám erre.
XAMPP van rajta, de free scriptekből idáig egy sem akart rendesen működni, pedig zenphoto és wordpress hiba nélkül fut rajta.
Tudtok javasolni scriptet erre a feladatra? -
#7721
biker
nagyúr
Sk8erPeter
#7720
biker
nagyúr
válasz
Sk8erPeter
#7720
üzenetére
Myisam tabla
Es ft min length 4, a keresett teszt szo mar 5
Vegig probalom a linkek tippjeit, ha felebredtem rendesen -
#7720
Sk8erPeter
nagyúr
biker
#7719
Sk8erPeter
nagyúr
Szerkesztettem még a hsz.-t, hozzácsaptam még linkeket, lásd a hsz. végét, hátha azoknak hasznát veszed.
Lehet, hogy ez is f@szság lesz, de itt ezt írják: [link]
"unfortunately InnoDB does not support FULLTEXT indices, so sometimes it is not an option…"
Nem lehet, hogy véletlenül a tábla szerkezetét átállítottad?Na, már megint egy: [link]
"Watch out for the VARIABLE ft_min_word_len -- it defaults to 4."
-
#7719
biker
nagyúr
Sk8erPeter
#7717
biker
nagyúr
válasz
Sk8erPeter
#7717
üzenetére
A myadmin osszes repair meg optim gombjat megnyomtam, de majd kiprobalom
Friss tabla, friss adatok, 4 dor az egesz tabla most meg -
#7718
Sk8erPeter
nagyúr
Sk8erPeter
#7717
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#7717
üzenetére
Itt is hasonló van:
"If you modify full-text variables that affect indexing (ft_min_word_len, ft_max_word_len, or ft_stopword_file), or if you change the stopword file itself, you must rebuild your FULLTEXT indexes after making the changes and restarting the server. To rebuild the indexes in this case, it is sufficient to do a QUICK repair operation:
mysql> REPAIR TABLE tbl_name QUICK;Alternatively, use ALTER TABLE with the DROP INDEX and ADD INDEX options to drop and re-create each FULLTEXT index. In some cases, this may be faster than a repair operation.
Each table that contains any FULLTEXT index must be repaired as just shown. Otherwise, queries for the table may yield incorrect results, and modifications to the table will cause the server to see the table as corrupt and in need of repair."
==
Még ezt is nézd meg a témában: [link], [link], [link] (alul, az incorrect results rész) -
#7717
Sk8erPeter
nagyúr
biker
#7716
Sk8erPeter
nagyúr
Lehet, hogy oltári nagy f@szság, de nem lehet, hogy REPAIR-elni kellene a table-öket? (de szépen hangzott
)
csak mert itt van ilyen, egy változó megváltoztatásánál:
[link]
"FULLTEXT indexes must be rebuilt after changing this variable. Use REPAIR TABLE tbl_name QUICK."
Mondom, lehet, hogy ennek semmi köze ehhez, csak egy próbálkozás...itt mondjuk nagyobb verzióra upgrade-elésről van szó, de itt is hasonlót írnak, hogy esetleg REPAIR kell, ha hülye eredményeket kapsz: [link]
"Incompatible change: For utf8 columns, the full-text parser incorrectly considered several nonword punctuation and whitespace characters as word characters, causing some searches to return incorrect results. The fix involves a change to the full-text parser in MySQL 5.1.12, so as of 5.1.12, any tables that have FULLTEXT indexes on utf8 columns must be repaired with REPAIR TABLE:
REPAIR TABLE tbl_name QUICK;" -
#7713
biker
nagyúr
Speeedfire
#7712
biker
nagyúr
válasz
Speeedfire
#7712
üzenetére
MySQL
Szerver: Localhost via UNIX socket
Szerver verzió: 5.0.92-community
Protokoll verzió: 10
Felhasználó: *************
MySQL karakterkészlet: UTF-8 Unicode (utf8)
WebszerverApache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
MySQL kliens verzió: 5.0.92
PHP-kiterjesztés: mysqlezen rossz
---
Szerver verzió: 5.0.38-Ubuntu_0ubuntu1.4-log
ezen meg jó, meg máson is -
biker
nagyúr
php és mysql kérdés. megőrülök...
felraktam egy új serverre egy webshop motor másolatát.
és a fulltext keresés nem működik!SELECT *, MATCH (termek_nev, termek_leiras, termek_cikkszam, termek_szall_code, termek_ean, termek_cimke) AGAINST ('teszt') AS score FROM webshop_termekek WHERE MATCH (termek_nev, termek_leiras, termek_cikkszam, termek_szall_code, termek_ean, termek_cimke) AGAINST('teszt') ORDER BY score DESC
Ez a régi serveren és localhoston és másik serveren is jó, ezen 0 eredményt ad
az indexek megvannak, készen vannak. ha elrontom, mert olyan mezőket adok meg, amire nincs index, ki is adja: nincs ilyen index, nem keres.
de a fentire keres, csak épp 0 találatot ad, bármire keresek.mi a fa.. lehet ez?
4x ellenőriztem, nincs elírva semmi -
#7710
Sk8erPeter
nagyúr
Speeedfire
#7708
Sk8erPeter
nagyúr
válasz
Speeedfire
#7708
üzenetére
Hát simán lehet, honnan tudjam
-
#7709
mobal
nagyúr
Sk8erPeter
#7707
válasz
Sk8erPeter
#7707
üzenetére
Nem tudom. Reggel feltöltöttem újra. Lehet valami "elveszett" az éterben.
-
#7708
Speeedfire
félisten
Sk8erPeter
#7707
Speeedfire
félisten
válasz
Sk8erPeter
#7707
üzenetére
Nem lehet, hogy a dns frissült lassan?
-
#7707
Sk8erPeter
nagyúr
Speeedfire
#7706
Sk8erPeter
nagyúr
válasz
Speeedfire
#7706
üzenetére
Most már semmi, ezek szerint sikerült megcsinálnia.
Tegnap még a szokásos Newhostingos átirányítós oldalt lehetett ugyanitt látni.
mobal: na, végül mi volt a megoldás?
-
#7705
Sk8erPeter
nagyúr
mobal
#7701
Sk8erPeter
nagyúr
Hát először azt nézd meg, hogy egy bármilyen index.php-vel ("Hello world") működik-e... Kétlem, hogy a Yii lenne a hibás, vagy ha mégis, akkor legalább valami hibát ki kéne írnia. Szerintem valamiért továbbra sem elérhető az index.php a yii-vel kezdődő aldomainen, azért rinyál.
(#7703) biker : ezt is próbáltam, annak idején ezt sem tudtam megszeretni annyira a kis erőforrásigényű progik közül, mint a Notepad++-t - de adok neki még egy esélyt, majd megnézem még.
-
#7703
biker
nagyúr
Sk8erPeter
#7698
biker
nagyúr
válasz
Sk8erPeter
#7698
üzenetére
Igen, csak bom nelkuli utf8-at tudok tudtommal
Linuxra egyet nezz majd meg: bluefish szerintem jo -
#7701
mobal
nagyúr
Sk8erPeter
#7700
válasz
Sk8erPeter
#7700
üzenetére
Valami oknál fogva mintha kevesebb lenne vele a szívás mind szerver, mind sortöréssel. Van index.php. Az van a mappában amit a Yii generál alapból. Ezért nem értem mit rinyál.
Szerk.: 23:36 most nem is működik...
Nyilván kliensoldali ellenőrzés sehol nem vált ki semmiféle szerveroldali ellenőrzést, ezt mindketten tudjuk, nem is tartozik szorosan a témához.
Mé', minek?
Miért nem elég, ha csekkoljuk isset()-tel, hogy megvan-e egyáltalán a checkbox típusú input (name szerint)?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nem értem a logikát.
Új hozzászólás Aktív témák
Hirdetés
- 16GB-os SODIMM (notebook) DDR4 RAM bazár - nézz be, lesz, ami kell neked!
- HP 15-af105nh laptop (15,6FHD/AmdQuad/4GB/128SSD/Magyar) - Akku X
- JOYOR S5 Pro 10" Elektromos Roller 26Ah Akkumulátorral Moddolt!
- XPS 13 9310 13.4" FHD+ IPS i7-1185G7 16GB 512GB NVMe ujjlolv IR kam gar
- Megkimélt Apple iPhone 8 Plus 64GB Fekete szinben, 100% akkuval, kártyafüggetlen, garanciával
- Bomba ár! Fujitsu LifeBook U7310 - i5-10GEN I 16GB I 256SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- ÁRGARANCIA! Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Chieftec 700W
- Bomba ár! Dell Latitude E7250 - i7-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Bomba ár! Lenovo ThinkPad L390 - i7-8GEN I 8GB I 256SSD I 13,3" HD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest