Keresés

Tipikusan www-data (vagy  www) userként fut az Apache/PHP; te meg mondjuk laja73 userként tudsz belépni FTP-vel vagy ssh-val. Nagy valószínűséggel közös csoportotok sincs, tehát csak az 'other' jogosultsággal tudsz dologzni (vagy haladó esetben ACL-lel, de még nem tartasz ott).

Mondjuk nem volna rossz, ha ez a megosztott mappa az Apache látókörén (tipikusan a public_html könyvtáron) kívül lenne, biztos ami sicher.

Na közben asszem megtaláltam a választ (egy oldalon, ami nem akart először bevezetni a Linux szépségeibe), eszerint a public. Azért megköszönöm, ha megerősíti valaki.

Folder permissions ügyben otthon van valaki? Én ugyanis nem😃, ha azt szeretném, hogy az oldalamon (de csak azon) keresztül bárki, aki amúgy hozzáfér, fel tudjon tölteni egy adott mappába, akkor rá az owner, a group vagy a public vonatkozik?

letöltesz a browserbe 5-10ezer sorokat és ott js-ből reszeled? hogy mik vannak! ez ma szokás?

OK, így marad! Ez nem bug, hanem feature :-)

Felületes voltam: a unicode karakterek már nem a sor végén vannak, de nem is mind van jó helyen: az Á és az A, és az É az E-vel egyenértékűnek számolva, de pl. a Č jó helyen jelenik meg (a C után: a Ča… a Cr… után, a D előtt jön). Ha lenne erre valami javaslatotok, az jól jönne.

SELECT *, @rownum := @rownum+1 AS posSK FROM manufacturers cross join (select @rownum := 0) r ORDER BY manStat ASC, manNameSK COLLATE utf8_slovak_ci;

A manStat nem lehet a hiba oka, az csak egy enum: 'a' vagy 'i'.

OFF:

OK, probléma leküzdve. Egy keveset utána olvastam és azt láttam, hogy js-ben a unicode rendezés hibás vagy nehezen járható, főleg nem 5-10e soros táblázatoknál. Úgyhogy a MySQL lekérdezésbe belevettem egy számlálót, php-val ebből HTML5 data-order attribútum készül, amire a dataTables vígan rendez.

:ON

Collate: ez az! Bár nem működik*, de erről volt szó itt régebben.

A SHOW COLLATION eredményében van több szlovák is, pl. az utf8_slovak_ci (sajtóhiba volt), az utf8mb4..., stb.

*: a gond már nem a MySQL lekérdezés eredményében, hanem kliens oldalon a dataTables-ben van. Majd leküzdöm azt is.

Köszönöm!

Addig is, míg esetleg előkerül valaki, akinek van benne gyakorlata:

"utf8-slovak-ci"? Az nem "utf8_slovak_ci" kellene, hogy legyen? (már feltéve, hogy nem sajtóhiba)

Ha az ORDER BY mezőnév mögé odaírsz egy olyat, hogy COLLATE utf8_slovak_ci, akkor sincs változás?

Egyáltalán: a szerver ismeri a szlovák karakterkészletet? Rohadt rég foglalkoztam mind mysql-lel, mind PHP-vel, de valami rémlik, hogy ezeket telepíteni kell...

Ha hozzáférsz egy mysql klienssel, akkor esetleg egy "SHOW COLLATION;" kimenetét nem ártana megnézni...

Help! Tudom, hogy erről már volt itt szó, de most nem találom az akkori választ a MySQL UTF8 kérdésre.

Egy szlovák honlapon dolgozok (bár nem beszélek szlovákul). Minden 'utf8-slovak-ci'-re van állítva (a kapcsolat, a táblák és az egyes mezők is), ORDER BY esetén a Č, az É és hasonlók mégis az ascii-ABC után jönnek, ráadásul rossz sorrendben (pl. az É a Č elé — fordítva kéne).

Hogy is kell ezt rendbe tenni?

A jogosultságokat sajnos nem tudom korlátozni. A szolgáltató hüje ötlete, hogy előfizetésenként 1 adatbázis 1 felhasználóval, így az az egy a shop admin, a guest és a júzer is.

A tárolt funkció dolog tetszik, kipróbálom.

a view semmi más, mint a select-ed letárolva. ha a view-ból queryzel, pont ugyanaz mintha az eredeti select-et adnád ki.

csinálj a forgalom táblára triggert, ami minden insert-re update-eli a termék táblát. ha jül értem a forgalom táblán nincs update/delete, ne is legyen.

nemtudom mennyire lehet tárolt eljárásokat csinálni mysqlben, csak lehet már. akkor írnék egy eljárást, ami az elad_termek(termekkod, mennyiseg, vevokod) . ezt hivna a UI, es ebben lekodolnek mindent amit csak kell. utanna le lehetne korlatozni a jogosultsagokat, hogy a UI kodnak ne is legyen joga a tablaba irni, csak olvasni meg futtatni az eladas eljarast.

Vajk

A view-t (amit most használnék először) a készlet állandó számolására használnám (kb 2e féle termék, napi ~1e látogató, kb. 20-100 vevő). Azt se gyorsítja?

Egyszerűbb lenne, ha egy termék egy sor lenne és abból vonnám ki / adnám hozzá a kétirányú forgalmat, de szükség van statisztikai adatokra, úgyhogy marad ez.

És ha két táblát használnék? Az egyikbe menne minden (napi 20-100 insert és <10 lekérdezés), a másikban egy sor per termék (napi ~1000 lekérdezés + 20-100 update), és a webshop onnan szedné az adatot (nem kéne 1000× összesíteni), az admin stat része meg a részletes táblából?

a view nem segit semmit. el kell mindenképp olvasnia az egészet hogy megtudja a készletet. zárást kell csinálni, és a sok sort a táblában lecserélni az egyenlegre.

Vajk

...azaz az előző SQL az alap volt, ahogy a tiédet átírtam. Az igazi ez (ellenőrzéssel, hogy mire van stockLimit beállítva):

    SELECT
        s.prID,
        p.prNameSK,
        p.prStockLimit AS Stl,
        SUM(s.stVol) as Stk
    FROM
        stock AS s,

        products AS p
    WHERE
        p.prStockAlert='y' AND
        p.prStockLimit IS NOT NULL AND
        s.prID=p.prID
    GROUP BY
        s.prID
    HAVING
        Stk<Stl*1.1

"ha jól értelek..."

Jól értesz :) Készletgazdálkodás és MySQL. Azokat a termékeket akarom kilistázni, amelyek a limit+10%-on belül vannak, hogy figyelmeztessen utánrendelésre.

A z adatmennyiségi problémára én is gondoltam. Az archiválás jó ötlet. Én első lépésként view-ba gondoltam tenni ezt a lekérdezést, azzal is gyorsítva a folyamatot. De van éves leltár, nincs akadálya az archiválásnak.

Nálam így működik:

SELECT p.prID, sum(s.stVol), p.prStockLimit
FROM products p, stock s
WHERE p.prID=s.prID
GROUP BY p.prID
HAVING SUM(s.stVol)<p.prStockLimit*1.1

Ha nincs a SELECTben a prStockLimit, nem megy a HAVING. Ez biztos valami eltérés a te SQL rendszeredtől.

Köszönöm a segítséget!

ha jól értelek, a stock tábla a mozgást tartalmazza, fel kell szummázni product-ta hogy megkapd a nettó pillanatnyi készletet.

(nem ide tartozik, de ez súlyos skálázási problémához vezethet évek alatt, kell csinálni időszakos zárásokat ahol a mozgásokat leíró sorok elmennek valami archívumba, es helyettesítődnek egy nyitókészlet sorral)

az a problémád, hogy a feltétel a szummára kell vonatkozzon. amit írtál az először kiveszi az alacsony készletet(készletmozgást) leíró sorokat (főleg a negatívok lesznek azok, mert azok aztán igazán alacsonyak, és utánna szummáz.

gondolom ez valami mysql, olyan max 30 percet használtam, de gondolom abban is működik ez:

select p.prodid, sum(s.svol)

from product p, stock s

where p.prodid=s.prodid

group by p.prodid

having sum(s.vol)<p.alertlevel;

ha a having nem volt meg, nézz utánna a doksiban. a lényeg hogy a először szűr a where, utánna aggregál a groupby. ha az aggregálás eredményére kell szűrni, arra való a having.

Vajk

'estét!

Azt hogy kell, hogy ha van egy products-táblám, benne stockLimit (riasztási limit, ha a termékből túl kevés van), és egy stock tábla, benne termékID és stockVol, ahol szerepel minden beszerzés és eladás, és szeretném lehúzni azoknak a termékeknek a listáját, amelyekből már kevesebb van, mint stockLimit+10%? Én így próbáltam:

    SELECT
        stock.prID,
        products.prStockLimit,
        SUM(stock.stVol) AS stVol
    FROM
        products,
        stock
    WHERE
        products.prID=stock.prID AND
        products.prStockAlert='y' AND
        stock.stVol<(prStockLimit*1.1)
    GROUP BY
        stock.prID

Ha a kék sor ott van, az stVol értéke mindig negatív, ha nincs, akkor a korrekt érték (a shop nem enged negatív készletet). Azon kívül, hogy valamit tutira rosszul írok, kéne egy kis magyarázat, hogy miért lesz negatív az stVol értéke, amikor nem is végzek rajta műveletet.

(kieg: ha minden komponens a helyi gépen van, akkor ssh kihagyható, cmd.exe elég;)

Először nem értettem, hogy 0.2s miatt mit pöcsöljek az ssh-val, de 5.2-nél már dereng :)

Ennek a scriptnek igazából csak egyszer kell lefutnia (9 éves, működő webshop adatainak importálása egy új rendszerbe), csak azt nem értettem, hogy egy sima PC tényleg ilyen gyors lehet-e. És tényleg nem :)

OK, egyből 5.2s körüli értékeket mutat. Mindjárt megnézem a doksit, hogy miért :)

Szerintem a microtime-nak adj egy true paramétert is: microtime(true);

Enélkül elég érdekes eredményeket kaphatsz, ha megnézed a doksit ;)

Az ilyesfajta műveletekhez ne használj böngészőt, ssh-vel lépjél be és a mysql saját eszközeivel vagy php-cli-vel csináld meg.

'estét!

Ha lekérdezek egy táblázatot úgy, hogy megkapjam a nem-ASCII karaktereket tartalmazó sorokat:

SELECT prID, prNameSK FROM products WHERE prNameSK != CONVERT(prNameSK USING ASCII) ORDER BY prNameSK ASC;

ami kb. 10.000 sorból 3.600 találatot ad, a prName-ből minden spéci szlovák karaktert angolra cserélek az str_replace-szel (pl. č = c ), aztán ebből 3.600 MySQL UPDATE sor születik és el is végződik (sima mysqli query, nem multi):

UPDATE products SET prNameEN='" . $name . "' WHERE prID=" . $key;

és ennek az egésznek a végén kiderül, hogy ez 0.238475s - 0.280159s időtartamot vett igénybe (közben a prNameEN mindig kinullázva), akkor piszok gyors a gépem, vagy nem elég úgy sebességet mérni, hogy a script 2. sora a SESSION_START után az, hogy:

$time_start = microtime();

az utolsó 2 meg:

$time_end = microtime();
echo $time_end - $time_start . "s";

A gép tényleg gyors (Core i7-4820K 4.00GHz, 16GB RAM, SSD RAID 950MB/s olvasás, 850 írás), a böngészőablak 3-4mp-ig üres, pedig csak az időt kell megkapnia a "szervertől" (localhost) és egy üres képernyőre kiírnia.

Akkor minden cool.

Jobb is így, hiszen nem mondat meg hogy mi azonos mivel, sem azt, hogy mit is akartál előállítani, és mi lett helyette... (persze értem, hogy főleg clairvoyantokra számítasz)

Bármikor :)

Felesleges, mert ellenőriztem a === segítségével, és azonosságot kaptam. 

Amúgy valószínűleg nem nálam van a hiba, az egész rapszodikusan reagál. Most például működik, holott hozzá sem nyúltam.

Mindenki hagyja tehát abba az őrült hibakeresést.

Rendes vagy, hogy ingyen adsz hibakeresési munkát, de inkább használd a var_dump-ot.

Sziasztok debuggerek! :)

Az MNB oldaláról le lehet hívni az árfolyamokat, az alábbi tömb deklarálása szükséges:

$param = array('startDate' => '2008-12-01', 'endDate' => '2008-12-30', 'currencyNames' => 'USD,EUR');

Ugye ezek példadátumok, átalakítva most így néz ki nálam:

$lastweekday=date('Y-m-d', strtotime('last weekday'));
$today_= date('Y-m-d');

$param = array('startDate' => $lastweekday, 'endDate' => $today_, 'currencyNames' => 'USD,EUR');

De nem működik, csak ha beírom kézzel a dátumokat, holott print_r($param) látszólag ugyanazt az outputot adja mindkét esetben (direkt beírva és változóval).

Sőt úgy veszem észre, a $today_ -jel nincs baja, csak a másikkal. Mi lehet a gond? Valami real escape vagy hasonló kéne?

(a teljes php fájl itt, a szükséges könyvtár itt, ha valakit érdekel)