Új hozzászólás Aktív témák
-
Taci
addikt
A szolgáltató 90 mp-ben maximalizálja a Cron Job-ok futási idejét.
Viszont van 1 szkriptem, aminek az összes elemen végig kell mennie néha, számolni, átírni stb. (ez a része most nem lényeges). És ez már most, 20e elem környékén sem fér bele a 90 mp-be. (duplájába se)Hogyan tudom ezt megoldani? Az oké, hogy mondjuk 85 mp-nél azt mondom, na most egy commit, aztán vége. De aztán valahogy triggerelnem kellene újra ezt a szkriptet, hogy folytassa, ahol az előbb abbahagyta. Viszont ilyenkor már a cron job le lesz állítva.
Nem állíthatok be 10-20-30 cron jobot, hátha mindre szükség van, hogy végig menjen az összes elemen.Hogyan lehet ezt megoldani?
Hátha van valalmilyen ötletetek. -
sztanozs
veterán
20e nem fér bele 90 mp-be? Ott valami nagyon el van b@szva. Ha adatbázisról van szó, akkor 20M-nak is bele kellene férjen ennyi időbe, hacsak nem rakéta-röppályákat számítasz a naprendszerben.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz sztanozs #20883 üzenetére
*Naprendszeren kívül - nagyban gondolkodom.
Ezért is írtam, hogy ez a része nem lényeges most. Nyilván átnézem újra, mindent logolva, mi tart mégis ennyi ideig.
Előbb futtat egy lekérdezést, ahol csak a rekordhoz tartozó verziószámot ellenőrzi. Ha nem a legfrissebb (amit egy tömbből ellenőriz a legelején), akkor ezekből visszaad egy listát (id-k).
Aztán ezen a nem legfrissebb verziójú rekordokon végig futtat pár ellenőrzést, sztringekből, és JOIN-olt táblákból dolgozik, aminek a végén kap egy eredményt, és attól függően kell a JOIN-olt táblákban update-elni, törölni vagy hozzáadni (vagy mindet).Ez legutóbb 6 percig tartott 8150 rekordnál.
Ahogy a részletes logot nézem, azt látom, hogy van olyan rekord, ahol akár 4 mp-be is kerül a processz, máshol meg 1 mp-en belül megvan 2-3.
Én is szívom a fogam, mert azért tényleg nem DNS-t vizsgál a szkript... De ezt úgyis átnézem, mert ez így sok.
Lehet, itt az én gépem (tesztkörnyezet - XAMPP) teljesítménye a szűk keresztmetszet, és szolgáltatónál repülni fog.De ettől függetlenül...
...csak annak az elvére szeretnék ráérezni, hogyan lehet vajon ezt megcsinálni, ha mindenképp kezelnem kellene ezt a helyzetet (szkript futása nem fér 90 mp-be bele).
Ma reggel az jutott eszembe, hogy vajon ha a Cron job meghívja a szkriptet, aztán azt 85 mp-nél commit-olom, majd meghívatom vele rekurzívan saját magát addig, amíg végig nem megy minden elemen, akkor vajon a 2. hívás (és a többi) még a Cron job-hoz tartozik?
Ezt fogom majd kipróbálni. -
pelyib
tag
Crontab tud tol-igot kezelni, tehat beallitod h x idotartamban hivja meg a skripted, nem kell tobb bejegyzes.
A scriptet meg ugy modositanam, h az elmenti az utolso feldolgozott elem IDjat vagy barmit amivel a kovetkezo futasnal meg tudja talalni a kovetkezot feldolgozando elemet.
Tehat az elso indulasnal 0rol indul, feldolgoz Y dbot majd leall, crontab inditja ujra, megnezi hogy mi volt az utolso es onnan folytatja. -
Taci
addikt
válasz sztanozs #20883 üzenetére
Már csak rákérdezek, mert ezt a feladatot nem látom máshogy (könnyebben, főleg gyorsabban) megoldhatónak:
Adott 40 kategória. Minden kategóriában vannak kulcsszavak, van, amiben csak 20, van amiben 240, van amiben 600.
Minden rekordhoz tartoznak szintén kulcsszavak, egy, vagy akár több is.A szkript ezeket a rekordokhoz tartozó kulcsszavakat vizsgálja végig a kategóriák kulcsszavain, az összesen, és ha valamelyikben egyezés van, azt a kategóriát bejegyzi neki.
Így alakul ki a végére, hogy az adott rekord milyen kategóriákba kerül.
Aztán ezek a kategóriás kulcsszavak változhatnak, bekerül pár, kikerül pár, és ez alapján a rekordokat is módosítani kell.A 90 mp jelenleg arra elegendő, hogy ezeket az ellenőrzéseket és bejegyzéseket megcsinálja kb. átlag 1200 elemhez.
Lefuttattam 3 mp-cel, 32-re volt ideje.Ezen akárhogy nézem, gyorsítani csak úgy tudnék, ha vagy kategóriákat törölnék, vagy kulcsszavakat. Egyiket sem akarom, sőt, kulcsszavakból egészen biztosan még több lesz.
Ez amúgy csak pár egymásba ágyazott
foreach
, semmi több:-- foreach - a kategóriák listájából a kategóriák neveire
---- foreach - a kategóriák neveihez tartozó tömb elemeire, amik a kategóriák kulcsszavai
------ foreach - a rekordokhoz tartozó kulcsszavakraEzután már csak a megfelelő rekordot hozza létre, módosítja vagy törli.
Ebben a kontextusban, ezekkel a számokkal is olyan szörnyűnek hangzik? Csak mert 0 viszonyítási alapom van, nem látnám, hogy bárhol "pazarolnék", nem tudom, hogyan lehetne ezen gyorsítani.
[ Szerkesztve ]
-
sztanozs
veterán
Ezt simán meg lehet csinálni SQL alapon mindenféle plusz kalkuláció nélkül is. Kellenek a következők:
- KATEGORIA tábla (ID, MEGNEVEZES)
- KULCSSZO tábla (ID, KULCS)
- M:N kötőtábla a Kulcsok és Kategóriák között (KUKA - KAT_ID, KULCS_ID)
- REKORDOK tábla (ID, ... mindenféle mezők ... )
- M:N kötőtábla a rekordok és kulcsok között (REKU - REKORD_ID, KULCS_ID)
Ezekkel simán SQL alapon lehet kimutatni a kategóriákat, mindenféle külön szenvedés nélkül:SELECT
R.*,
GROUP_CONCAT(KAT.MEGNEVEZES)
FROM REKORDOK AS R
JOIN REKU ON R.ID=REKU.REKORD_ID
JOIN KUKA ON REKU.KULCS_ID = KUKA.KULCS_ID
JOIN KATEGORIA AS KAT ON KUKA.KAT_ID = KAT.IDKb fejből, de lehet, hogy kell egy nested select:
SELECT
R.*
RK.KATEGORIAK
FROM REKORDOK JOIN
(SELECT
R.ID,
GROUP_CONCAT(KAT.MEGNEVEZES) AS KATEGORIAK
FROM REKORDOK AS R
JOIN REKU ON R.ID=REKU.REKORD_ID
JOIN KUKA ON REKU.KULCS_ID = KUKA.KULCS_ID
JOIN KATEGORIA AS KAT ON KUKA.KAT_ID = KAT.ID
GROUP BY R.ID) AS RKAT ON R.ID = RKAT.ID[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
biker
nagyúr
Elég furának tartom, hogy "ész nélkül" kapcsolatokat állítunk fel, miért nem akkor keresünk kapcsolatokat amikor kell? Ha ez valami kereső, ami kategóriák közt keres, akkor főleg.
"ész nélkül" értsd nem akkor amikor kell, nem úgy ahogy kell, és nem csak azon a rekordokon amin kellElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Taci
addikt
válasz sztanozs #20888 üzenetére
Mindenek előtt köszönöm, hogy kódot is írtál!
Viszont talán nem egy dologról beszélünk. (simán benne van, ti látjátok a jó utat, én meg továbbra is vakon vagyok)
SQL-lel nem lehet (jelen pillanatban) ezt megcsinálni, mert a kulcsszavak nem táblázatban vannak, hanem simán egy tömbben.
De amúgy ha a kulcsszavak táblázatban lennének, akkor sem lenne gyorsabb szerintem, sőt, hiszen azért csak gyorsabb egy kész tömbön végigmenni, mint előtte a tömb elemeit SQL-ből lekérni.Mutatok egy éles példát:
Külső forrásból ez a sztring érkezik:
$rekord_kulcsszavak = "Kultúra,előzetes,eufória,filmtv,hbo,második évad,rév marcell,sam levinson,sorozat,zendaya";Ezt szétbontom tömbbe, elemenként.
Ezeket az elemeket egyesével megnézem, milyen kategóriákhoz tartoznak (a kategóriákhoz tartozó kulcsszavak alapján), és azokat írom be a KUlcsokKAtegóriák táblába:
- Kultúra --> kultura
- előzetes --> szorakozas
- eufória --> nincs ilyen kulcsszó
- filmtv --> nincs ilyen kulcsszó
- hbo --> szorakozas, már benne van a kategóriában, skip
- második évad --> nincs ilyen kulcsszó
- rév marcell --> nincs ilyen kulcsszó
- sam levinson --> nincs ilyen kulcsszó
- sorozat --> szorakozas, már benne van a kategóriában, skip
- zendaya --> nincs ilyen kulcsszóTehát a rekordhoz a kultura és a szorakozas kategóriák kerülnek mentésre.
@biker: Amikor bekerül egy rekord a fő táblába, az az infó is mentve van vele, hogy milyen verziójú kategória tömb alapján lett kategóriákba besorolva. Így amikor ez a szkript elindul, elsőnek csak azt ellenőrzi, melyik rekordnál van más (régebbi) verzió. Így csak azokat a rekordokat nézi át, amik régi verzióval készültek. Nincs felesleges művelet.
Viszont ha aztán frissítenem kell a kategóriákhoz tartozó kulcsszavakat, akkor muszáj vagyok emelni a verziószámot is, mert nem tudhatom, melyik rekord fog új/más kategóriá(k)ba kerülni.A fenti példánál maradva:
Mondjuk azokkal a kulcsszavakkal az 1.0-s verzióban a következő kategóriákba kerülne a rekord: kultura, szorakozas, és mondjuk az "eufória" miatt a masszazs kategóriába (csak egy példa).
Aztán ezt észreveszem, hogy hopp, az "eufória" kulcsszó nem jó a masszazs kategóriába, úgyhogy kiszedem onnan.
Ekkor ha nem emelek verziót (1.0 marad), akkor az a rekord skippelve lesz, így marad a masszazs kategóriában, hibásan.
De verziót emelek (1.1 lesz), így újra ellenőrzive lesz, és kikerül a rossz kategóriából. De ennek sajnos az az ára, hogy verzióemelésnél mindet újra át kell nézetnem, mert nem tudhatom, melyik fog változni, addig, amíg nem ellenőrzöm újra. Viszont a következő változtatásig ez a szkript skippelni fogja az összeset már, mert 1.1-re át lett írva mind. -
biker
nagyúr
Én a leírásból valami nagyon rekurzív megoldást látok.
amit írsz, az szerintem a klasszikus cimkézés, ahol egy rekordhoz a cimkék el vannak tárolva, és abban fulltext search a barátod, match against....
Ha nem akarod nagyon rekurzívvá tenni, akkor a cimkék is táblában
CimkeTabla id, cimke
Rekordok id, nev, akarmi, cimkek
és a cimkékben id-k felsorolva. De a fulltext search jól dolgozik indexelt táblákkal.Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
sztanozs
veterán
Ezért is kell a kulcsszavakat és a kategóriákat táblázatban tárolni.
Ha táblázatban tárolod indexelve, akkor nem full table search lesz (azaz nem három egymásba ágyazott foreach), hanem Hash/B-Tree search, ami sokkal jobb.
De még két hashset/dictionary is jóval gyorsabb lenne, mint két lista.
https://www.php.net/manual/en/book.ds.php
http://docs.php.net/manual/en/class.splobjectstorage.phpJOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
Amúgy hogy kerülnek bele a kulcsszavak a tömbbe, és miért nem táblában vannak tárolva dinamikusan?
Amúgy ha érdekel python implementáció, azt is tudok írni, de a php elég szegényes az ilyen jellegű feldolgozás terén.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
Különbség a full list scan (foreach) és hashset között:
>>> # 456.976 elem listában
>>> A = ['AAAA', ..., 'ZZZZ']
>>> # 456.976 elem hasset-ben
>>> B = set('AAAA', ..., 'ZZZZ')
>>> # 2000 elem egy listában ami random négy karakter (~85% találati valószínűséggel)
>>> C = ['@ABC', ..., 'XYZ@']
>>> # keresés eredmények másodpercben
>>> timeit.timeit("[c in A for c in C]",number=1,globals=globals())
10.154
>>> timeit.timeit("[c in B for c in B]",number=1,globals=globals())
0.000786
Azaz míg 2000 elem megkeresése végigiterálva a félmilliós listában 10 másodpercig tart, addig ugyanannyi idő alatt 20.000.000 (húszmillió) elemet le lehet ellenőrizni egy félmilliós adattartalmú hashset-ben.[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
-
sztanozs
veterán
válasz sztanozs #20895 üzenetére
és egy némileg lassabb implementáció PHP-ben:
<?php
$A = [];
$B = [];
foreach (range('A', 'Z') as $a){
foreach (range('A', 'Z') as $b){
foreach (range('A', 'Z') as $c){
$A[] = $a.$b.$c;
$B[$a.$b.$c] = 0;
}
}
}
echo count($A).'<BR>';
echo count($B).'<BR>';
$time_start = microtime(true);
for($i=0; $i<10000; $i++){
in_array('ZZZ', $A);
}
$time_end = microtime(true);
$execution_time = ($time_end - $time_start);
echo $execution_time.'<BR>';
$time_start = microtime(true);
for($i=0; $i<10000; $i++){
key_exists('ZZZ', $B);
}
$time_end = microtime(true);
$execution_time = ($time_end - $time_start);
echo $execution_time.'<BR>';
?>A különbség 1 sec vs 0.5 milisec.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz sztanozs #20893 üzenetére
#20894: Ah, az azért már nem elhanyagolható sebességbeli különbség... Csak jó lenne tudni ki is használni.
A Pythonba nem kezdenék bele, bőven elég ez is, köszönöm. Látod, ezzel sem haladok épp villámtempóban.
A tömbbe a kulcsszavakat kézzel írom bele. Jönnek külső forrásból a bejegyzések, hozzájuk az általuk megadott kulcsszavak, tagek, kategóriák, én pedig azokat rendezgetem magamnak a saját kategóriáimba. (Enélkül nagyon össze-vissza lenne minden, átláthatatlanul.)
Ezen a táblázatos tároláson el kell gondolkodnom, ki kell próbálnom. És igazán nem is értem.
Most simán csak in_array()-jel nézem meg, hogy az adott kulcsszó benne van-e valamelyik kategóriához tartozó kulcsszavai között. De ehhez ugye végig kell mennem a külső forrásból megadott kulcsszavakon (foreach), aztán a kategóriákhoz beállított kulcsszavakon is (foreach).
Ha táblázat van tömb helyett, az én tapasztalatommal kapásból feltöltenék egy tömböt a táblázat adaival, és foreach-et használék, hogy bejárjam. De sejtésem szerint nem ez az ajánlásod lényege.(A linkeket átnézem alaposan, amint odaérek. Köszönöm.)
Upd.: És azt is, amit most küldtél, még csak most látom, a hozzászólás elküldése után. Köszönöm szépen ismét a segítségedet és a türelmedet!
[ Szerkesztve ]
-
sztanozs
veterán
Igen, az in_array sinám végigiterál, amíg meg nem találja, míg a másik változat (key_exists) esetében azt a tulajdonságot abuzáljuk, hogy a kulcsok hash-elve vannak tárolva és sokkal gyorsabban kereshetők, mint maga az adat.
Mivel nincs rendes Set megoldás (illetve a DS/Set nincs alapból telepítve), így a tömb asszociatív kulcs keresés megoldását lehet abuzálni, hogy sebességben sikert érjünk el.
Ezzel a módszerrel tárolhajuk az összefüggéseket két irányból is:<?php
$kategoriak = array(
'szorakozas' => ['elozetes', 'film', 'sorozat', 'hbo', 'mozi'],
'kultura' => ['mozi', 'szinhaz', 'múzeum', 'koncert', 'film'],
'masszázs' => ['eufória']
);
$kulcsok = [];
foreach($kategoriak as $kat => $v) {
foreach($v as $kulcs) {
if (key_exists($kulcs, $kulcsok)) {
$kulcsok[$kulcs][] = $kat;
} else {
$kulcsok[$kulcs] = array($kat);
}
}
}
var_dump($kulcsok);[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz sztanozs #20898 üzenetére
Tehát ha jól értem, akkor ebből
$kategoriak = array(
'szorakozas' => ['elozetes', 'film', 'sorozat', 'hbo', 'mozi'],
'kultura' => ['mozi', 'szinhaz', 'múzeum', 'koncert', 'film'],
'masszázs' => ['eufória']
);
ezt csináltad:
$kulcsok = array(
"elozetes" => "szorakozas",
"film" => "szorakozas",
"film" => "kultura",
"sorozat" => "szorakozas",
"hbo" => "szorakozas",
"mozi" => "szorakozas",
"mozi" => "kultura",
"szinhaz" => "kultura",
"múzeum" => "kultura",
"koncert" => "kultura",
"eufória" => "masszázs",
);
És akkor azt mondod, hogy így ezen belül az array_key_exists (key_exists) gyorsabban megtalálja az értéket, és egyből ott van hozzá a kategória neve is értékként.
Kipróbálom, köszi.Reggel amúgy rákerestem arra, hogy "php in_array slow performance", és volt egy válasz valahol, ahol azt ajánlotta, hogy a
$categories_szorakozas = array(
"elozetes",
"film",
"sorozat",
"hbo",
"mozi",
);
helyett legyen:
$categories_szorakozas = array(
"elozetes" => true,
"film" => true,
"sorozat" => true,
"hbo" => true,
"mozi" => true,
);
és így array_key_exists-tel ellenőrizni. Átírtam, futtattam egy tesztet (előzővel és ezzel is ugyanúgy 10 mp-re limitálva), és az in_array 10mp alatt 77 rekordot tudott feldolgozni, míg ez a másik fajt az array_key_exists-tel csak 38-at... Szóval vissza is írtam.
De a te változatodnak sokkal több értelme van, szóval teszek azzal is egy próbát.
Meg amúgy (bár nem hiszem, hogy túl sok időbe kerül az a kezdeti, "kulcsok" táblát feltöltő művelet, de) megcsinálhatom eleve úgy a "kategoriak" tömböt, hogy eleve abban a formában legyen. -
Taci
addikt
Átírtam, most már a megadott 80 mp alatt kb. 6500 elemmel végez (az eddigi 1100-hoz képest). Igazából nagyobb ugrásra számítottam, mert egy 1 milliós táblát nézve ezt bizony elég sokszor kell hívogatnom.
Megpróbálok "lekapcsolni" részeket belőle, hogy lássam, mi fogja vissza ennyire. -
Taci
addikt
foreach ($rekord_kategoriai as $rekord_kategoriai_value){
if (array_key_exists($rekord_kategoriai_value, $kulcsok){
//
}
}
A $kulcsok tömbben kb. 3000 elem (kulcsszó - kategória páros) van.
A $rekord_kategoriai-ban átlagban 5-10 elem.Itt mi lenne az elérendő cél sebességben? Tényleg még csak viszonyítási alapom sincs.
Ahogy írtam, most kb. 6500 elem 80 mp alatt.Ez tehát 1 mp alatt 80 elem. 80 elemnél elemenként mondjuk 10 kulcsszó, ezeket egyesével 3000 kulcsszó-kategória párossal összehasonlítani. (bár ugye az array_key_exists-tel ez elvileg gyors)
Bocs, hogy ezzel nyaggatlak titeket, de tényleg nem tudom, meddig is lehet ezt javítani. Lehet, már elértem ezzel egy ideális sebességet? Lehet, a 1/100-át sem.
[ Szerkesztve ]
-
#45252096
törölt tag
Erre [link] van ennel jobb megoldas ? (Gyakorlatilag dupla 1-N kotes, mert egy csapatnak ki szeretnem iratni a meccseit ha otthon vagy idegeben jatszik.
class Team extends Eloquent
{
public function allMatches() {
return $this->hasMany('Match', 'visitant_id')->orWhere('local_id', $this->id);
}
}
[ Szerkesztve ]
-
Sziasztok!
Alkalmazok egy egyszerű PHP kódot, ami megnyit egy, a szerverre feltöltött txt fájlt és módosítja. Működik, hibátlan.
Csakhogy. Ha olyan url-re mutat rá, ami nem létezik (pl bent van egy mappában, de a PHP kód egy másik mappát hív be), akkor létrehozza. Az én kódom így néz ki:<?php $file=fopen("file.txt", "r");
$db2=fread($file,"1024");
fclose($file);$db2=$db2 + 1;
$fp=fopen("szamlalo.txt", "w");
fwrite($fp, $db2);fclose($fp);Ezt lehet módosítani úgy, hogy csak akkor írjon bele a fájlba, ha az létezik? Vagyis hogy ne hozzon létre újat, ha nem találja?
Előre is köszönöm!
But who is watching the guardians?
-
Köszönöm válaszaitokat!
But who is watching the guardians?
-
sztanozs
veterán
Igazából nem tudom mi lehet nálad a gond. A két megoldás között nagyságrendi különbségnek kellene legyen. Lesz a kódban valami más is, ami lassítja a futtatást. Ha gondolod PM-ben esetleg tudok többet segíteni...
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taci
addikt
válasz sztanozs #20912 üzenetére
Nagyon szépen köszönöm a felajánlásodat, de nem foglak privátban zaklatni ezzel. Az egy dolog, hogy beírom ide, aztán ha valaki épp rálát és rá is ér, ad 1-2 tanácsot - de amíg van mit átéznem saját kútfőből is, semmiképp nem fogok mást piszkálni ezzel.
Kb. 1100 rekord / 80 mp-ről indultam optimalizálni, kb. 18e / 80 mp körül van most, de ha azt mondod, ez még mindig nem az igazi, átnézem a többi részt is. (Igazából élvezem, persze sok időt elvisz egy olyan területre, amiről azt hittem, már készen van, de attól még élvezem. )
Köszönöm még egyszer a felajánlást!
-
Mike
veterán
a kulcsszavak külön táblában tárolnám, az egyes címeket is, és ezek azonosítóját egy harmadikban. a kulcsszavak unique-olva lennének, így egy sima insert elég arra hogy betegyem ami még nincs benne. azt, hogy ne lehessen elütésekkel mindig ugyanolyan kulcsszavakat megadni a felszínen oldanám meg.
a rendezgetés részt nem értem, a szoftvered mi alapján rendezgetni? vagy írtál hozzá egy AI-t? de úgy is tudod csinálni, hogy a felszin eleve feladja a backnek, az id-kat. ha nem akarsz belső id-kat megadni, használd az uuid-t van SQL alatt UUUID(), de a rövidített változat is eléggé unique, tehát LEFT(UUID,8)de úgy látom az adatbázist ajánlotta már más is.
-
Taci
addikt
Köszönöm a tanácsot és a segítő szándékot, de sztanozs "unszolására" (jó értelemben véve persze ) átnéztem újra, és meglett, hogy az SQL-es Update miatt volt lassú, amúgy nagyon gyors a logikai/ellenörzős rész.
A lassúság oka az volt, hogy egyesével futtattam rekordonként az Update-et... - de most már átírtam arra, hogy csak egyszer a végén, az összeset bind_param-mal átadva, egy lépésben futassa, és így már repül.
(Érdekes volt így kilogoltatni, hogy hogyan is néz ki egy darab, 23e rekord adataiból összerakott lekérdezés. )Köszönöm azért így is a tanácsot!
Új hozzászólás Aktív témák
- Gamer PC Intel i5 9400/16GB DDR4/GTX 1660 6GB/256GB SSD/500/GB HDD/Beszámítás/Garancia/
- Gamer PC Ryzen 1600X/16gb ddr4/GTX 1660 SUPER 6gb/256gb ssd/500gb hdd/Garancia/Beszámítás/
- Palit Geforce RTX 3060 12GB /CSAVARMATRICA/GYÁRI ÁLLAPOT/BESZÁMÍTÁS/
- G.SKILL 32GB KIT DDR5 6000MHz CL30 Trident Z5 NEO AMD EXPO - Alza jótállás 2032-ig
- ZEN Gamer PC - GTX 1660 Ti - Ryzen 3600 - 16GB DDR4 - 1TB m.2 SSD
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen