Új hozzászólás Aktív témák
-
Male
nagyúr
válasz
bambano
#4360
üzenetére
Ha a neten van, és nem tudja az elérhetőséget meg a user/passt, mert hardkódolva van a programban? Legalábbis feltételezem, hogy a program felhasználói felülete nem olyan, hogy a pincérek gépelgethetik be az SQL utasításokat, és egy sima config szövegfile sem tuti hogy van ezekről amiből kinézhetné.
...de már lényegtelen, mert kiderült, a gépen van az SQL szerver nála. -
-
kezdosql
tag
válasz
bambano
#4203
üzenetére
Igen, felreertetted teljesen.
A Clipper az egy jo megoldas volt a problemara, hogy laikusokat tavol kell tartani az adatoktol.
dBase adatbazisokat kezelt (szerintem inkabb tablakat, mert sql akkor meg nem volt) es dBase programokat hasznalt, kesobbi verzioja mar mas programokbol is elfogadott bizonyos reszeket.A nagy elonye az volt, hogy amikor a forraskodok keszen voltak, a program minden resze mukodott, akkor leforditva volt egy exe program azt kellett elinditani, es a buta user csak azt tehette, amit a menuk reven elerhetett. A buta user boldog volt, mert latta az adatokat menuben, listaban, tablazatban, ahogy menuk kozott valtott, es biztonsagos volt, nem volt lehetoseg adatokba belebarmolni.
Az sql megjelenesevel kellett egy php, vagy c vagy mas program, amivel lehetett kezelni es megjeleniteni az adatokat, majd jott a bongeszos megoldas, amihez html, css es javascript is kellett, es persze servert kell telepiteni, frissiteni, upgradelni, stb.
A buta userek pedig ragaszkodnak a tablazatkezelos megjeleniteshez, mert ok azt ertik, ezert el az excel evtizedekkel az elavulasa ota is.
A kerdesem az volt, hogy van-e olyan megoldas, hogy amikor kesz egy sql adatbazis lekerdezeset es megjeleniteset megoldo forraskod, azt leforditva van egy exe fajl es nem kell servert telepiteni, stb.
Egy jo pelda a hataridonaplok esete. Rengeteg egyszeru es bonyolult megoldas letezik ra, valoszinuleg a tobbseget c-ben vagy hasonlo nyelven irtak, de egyikkel se lehet teljes koru keresest vegezni, mert mindegyik csak a dBase-n alapulo szemlelettel mukodik, egy szempont szerint lehet keresni, komplex modon nem, amit az sql lehetove tesz.
Most szenvedunk rendesen, mert kenyszerusegbol egy excel tablaban vannak adatok, amit jellemzoen negyfele adat - datum, meret, szin, hely - tetszoleges kombinaciojaval kell keresni, amihez az excel tablat mindig at kell rendezni, emiatt allandoak user error-ok.:-(
Ha lenne egy egyszeru alkalmazas, ami csak annyit tud, hogy negy adat tetszoleges kombinaciojara lehet vele keresni, sot szurni a megjelenitendo adatokat, meglenne a boldogsag.
-
-
Louro
őstag
válasz
bambano
#4197
üzenetére
A HAVING-et általában subselect-tel oldják meg az emberek. Az első kettő az nagyon alap. A 3. feladatnál csak arra voltam kíváncsi, hogy kétségbeesik vagy nem. HAVING simán helyettesíthető. Csak azzal elengánsabb.
Már a 2. olyan kolléga van mellettem, akik több év elemzés után nálunk találkozott a ROW_NUMBER()-rel. Én meg amikor autodidakta módon tanultam, annyira alapnak véltem.
De az se mindegy, hogy mennyi tábla van összekötve. Előző osztályvezetőnk olyan kódot írt, amiben legalább 15 tábla volt LEFT JOIN-nal összekötve. (MSSQL.) Tetű lassú volt. 4-4,5 órát futott. Azzal, hogy szétszedtem 4 részre, 20-30 perc alatt megvolt az eredmény. Semmi mást nem néztem, de van egy olyan érzésem, hogy lehetne performanciát javítani.
Itt arra akarok utalni, hogy nem elég, hogy valaki ismeri a főbb parancsokat, igényesnek is kell lenni és gondolni kell arra, hogy limitált az erőforrás. (A rengeteg temptábláról nem is beszélve. Egy hónapig takarítottam, a GDPR bevezetése előtt.)
Speciális dologkra interjún nem is kérdeztem, mert úgyis ott a gugli. Én is használom, ha elakadok vagy keresek gyorsabb, jobb megoldásokat. Hülyeségnek tartottam mindig, ha interjún valaki nagyon mély ismeretre kérdezz. A jelentkező is lehet tudna olyat kérdezni, amit meg az interjúztató nem tudna :/
-
#4180
Apollo17hu
őstag
bambano
#4179
Apollo17hu
őstag
válasz
bambano
#4179
üzenetére
Nem, vagyis én próbálok mindig a legjobb tudásom szerint kódolni, de mezei kontrollerként nem értek az optimalizáláshoz. Egyébként azt a 20 darab allekérdezést össze tudnám gyúrni 5-6-ba, de akkor egy potenciális jövőbeli hibakeresés sokkal tovább tartana (nekem is, de méginkább olyasvalakinek, aki nem ismeri a kódot). Az én szemszögemből az lenne a legegyszerűbb, ha egy táblából tudnék leszedni mindent, de a mostani mókolás is azért kellett, mert nincs IT erőforrás a fejlesztésekre.
Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód.
-
válasz
bambano
#4176
üzenetére
Az adatbázisban int-ek az adatok, de ahol 0 a beérkező hívás, ott nincs értelme megválaszolási arányt számolni, ezért szeretnék az arányszám helyett 'N/A' string-et kiíratni.
Közben sikerült megoldanom
CASE WHEN CAST(app.CallsOffered as INT) = 0 THEN 'N/A'
ELSE CAST(app.CallsAnswered*1.0/CallsOffered as VARCHAR) end as AnswerRateKöszönöm a segítséget
-
#4174
Apollo17hu
őstag
bambano
#4171
Apollo17hu
őstag
válasz
bambano
#4171
üzenetére
Volt korábban ugyanezzel a kóddal memóriaprobléma, de az egyértelmű volt, mert 15 perc után hibaüzenettel leállt. Szerencsére rájöttünk az okára (kb. az volt, hogy a 20 allekérdezés miatt 3^20 szorzót kapott a memóriában elfoglalt mérete, de extra kötésekkel, ezt áthidaltuk).
Temp tábla sajnos nem játszik. Maga a keretrendszer úgy néz ki, hogy különálló sql-eket tárolunk, amelyeket egy alkalmazás minden nap meghív, lefuttat, az eredményt pedig Excelbe másolja. Nincs lehetőség egymásra épülő kódrészletek megadására.
@bpx: Jogos, fejből írtam, de élesben jó helyre raktam a hintet. Ezt a materialize-t még kipróbálom, mert tényleg annyira lenne csak szükség, hogy külön-külön meglegyen az allekérdezések eredménye, utána már 2 másodperc alatt kiszámolja.
-
válasz
bambano
#4148
üzenetére
ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz
Elméletileg pont fordítva. A NOT IN-hez kell iterálni, az NOT EXISTS anti-joinra konvertálható (csak ebben a formában szebb).Analyse jól írja, mert tényleg pont fordítva van, mert az exists és a left join + null is anti-joinra van optimalizálva, a not in pedig hashed subplan (mert az IN értéket és null-t is visszaadhat, ezért kétszer fut az iteráció - ki elemszámnál ez nem probléma, de nagy elemszámnál már lesz különbség, ráadásul a subplan miatt cache problémák lehetnek).
EXPLAIN ANALYZE
It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows. -
Tanisz
senior tag
válasz
bambano
#3820
üzenetére
Azért ez nem ilyen egyértelmű, de jó amit írtál, teljesen rendben van, abszolút jogos. Egyetértek.
Viszont az árnyaltság miatt: hiszen, ha ő azért gyűjti az adatokat programmal is akár a weboldalról, hogy a saját autóvásárlásához segítse magát, és szűrt, szempontok alapján adatok érdeklik csak amiket később kielemez, az kb ugyanaz, mintha excelbe kézzel bepötyögné és onnan alkotna halmazokat és eredményeket saját magának.
Ez nekem nem volt egyértelmű Johnny_vT kérdéséből, bár lehet benéztem
Viszont amit Te is írtál, hogy azért gyűjtené az adatokat, hogy egy 3. személynek vagy személyeknek nyújtson információkat belőle akár haszonszerzés miatt is, az valóban adatlopás és személyes adatokhoz fűződő adatvédelmi jog megsértése.
-
Johnny_vT
senior tag
válasz
bambano
#3817
üzenetére
Nem vitatkozni akarok, hiszen az ügyben nincs tapasztalatom. Viszont logikailag nem látom miért lenne a hirdetett járművek adatainak begyűjtése jogsértő, hiszen azok teljesen nyilvánosan publikált adatok, amiket én is, te is bármikor elérhetünk a weboldalon. A különbség, hogy nem a mobile lassú kezelőfelületét kell nyomkodni hozzá, hanem egy Excel táblát / adatbázist pörgetni.
Analógia (szerintem): mintha egy koncerten egyesével kéne mindenkitől megkérdezned, hogy milyen színű pólót hord, de ehelyett te a lelátóról összeszámolod magadnak.
A személyes adatok (mint név, telefonszám) ehhez szükségtelenek is lennének. Bár az tény, hogy valószínűleg csak egy extra lekérdezésen múlna azok kigyűjtése is, azaz a lehetőség adott rá (de ezek is nyilvánosan az oldal minden user-ének).
-
kw3v865
senior tag
válasz
bambano
#3748
üzenetére
@bambano
A célirányos indexek mit jelentenek tulajdonképpen? Hol tudok erről olvasni angolul? Most térbeli indexeket használok, ez sokat segít, ezek nélkül sokkal lassabb lenne.
@VirsLee
Autóban van a rendszer, valós időben kell működnie, max. 100 km/h-ig, de többnyire 80 alatt (teljesen offline, minden localhoston). Kapja a koordinátákat a nagy pontosságú GPS-től, és elsősorban térbeli lekérdezéseket kell futtatni. Jelenleg szimulálva megy a dolog, egy korábban rögzített track alapján, most éppen 25 ms-st állítottam be frissítési gyakoriságnak. ilyen gyakorisággal hívja meg a függvényeket. Többnyire PostGIS-es függvényeket használok, de ezeket kombinálom is általában, pl. a legközelebb lévő objektumok távolságát kell kiszámolni, vagy jeleznie kell, amikor az autó egy poligon területére megy rá, ilyenek. Alapvetően egyelőre meg vagyok elégedve a teljesítménnyel, de amikor bővülni fognak a funkciók (nem csak SQL, egyebek is), akkor azért már számíthat, hogy mennyi erőforrást igényel, sajnos a hardver teljesítménye korlátozott (bár aránylag jónak mondható). -
kw3v865
senior tag
válasz
bambano
#3666
üzenetére
Köszi a tippet, utánanézek. Eddig nem kellett foglalkoznom különösebben a performanciával, de most fontossá vált.
Még arra gondoltam, hogy az elején a CASE WHEN ST_Intersects(p.geom,pr.geom) then 'TRUE' ELSE 'FALSE' vajon elhagyható-e valahogy? Mert ugye most az ST_Intersects függvényt kétszer hívja meg, hiszen a JOIN is ezen alapul. Nekem az a cél, hogy ne csak a TRUE, hanem a FALSE rekordokat is lekérdezzem. Jobb módszert egyelőre nem találtam.
-
nyunyu
félisten
válasz
bambano
#3645
üzenetére
Ilyesmi feladatba már sikerült belefutnom melóhelyen.
Ottani kódom erősen leegyszerűsítve.DB adminjaink persze nem szoktak szeretni érte, amikor több millió soros táblákból kell kibogarásznom pár tízezer hasznos rekordot, majd azokat intervallumokba rendezni...
Query plant kielemezve mindenféle Cartesian join kerülendő szakszavakkal dobálózva próbálják levenni a rontást a DB performanciáról. -
tm5
tag
válasz
bambano
#3645
üzenetére
Ezt sqlfiddleben raktam össze:
/*schema setup:*/
create table t1(c1 integer);
insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);
insert into t1 values (4);
insert into t1 values (6);
insert into t1 values (7);
insert into t1 values (10);
insert into t1 values (11);
/*a query:*/
select * from (
select c1,
CASE
WHEN plus1 != kovetkezo THEN 'vegelem'
WHEN minus1 != elozo THEN 'kezdoelem'
WHEN elozo IS NULL THEN 'kezdoelem'
WHEN kovetkezo IS NULL THEN 'vegelem'
ELSE 'kozbulso'
END tipus
from
(select c1, c1-1 minus1, c1+1 plus1, lag(c1) over () elozo, lead(c1) over () kovetkezo from t1) t) tt
where tipus != 'kozbulso';ezután már csak egy pivot kéne, de arra már nem volt energiám
-
bpx
őstag
válasz
bambano
#3100
üzenetére
Azért, mert akkor született a döntés a napok kihagyásáról, és az Oracle meg fogta magát, és ezt vette alapul. Kipróbáltam, a területi beállításoknak erre nincs hatása, tehát én hiába állítom pl. UK-ra, attól még nem fogja az 1752-t 355 naposnak számolni, hanem ugyanúgy 1582-t mondja rövidebbnek.
-
Novics
senior tag
válasz
bambano
#3087
üzenetére
3 lekérdezés? Egyikben a szemad-ban a névhez tartozó jogvisz_kezd, a másikban a kmh-ben a dolg-hoz tartozó min(kezdet) where beszamithato. Mi a harmadik?
Találtam egy jónak tűnő leírást az unionról, de még nem volt időm átrágni magamat rajta. Arra gondoltam, hogy berakom egy táblakészítő lekérdezésbe, aztán utána arra is ráeresztek egy min()-t. Ez az igazán kőbalta, vagy inkább sima husáng megoldás! -
-
bambano
titán
válasz
bambano
#2987
üzenetére
közben az én agyam is járt, és eszembe jutott a régi jó gépikód. és kiderült, hogy van bitenkénti or aggregátor függvény.
select customer_id,bit_or(sid) from (
select customer_id, case
when service_type_id=11 then 1
when service_type_id=13 then 2
end sid from service) cc group by 1;ezt beágyazva még egy subselectbe, lehet grouppal darabszámot számolni.
kösz az ötletet, azon indultam el.
-
tm5
tag
válasz
bambano
#2987
üzenetére
select cc.szolgaltatas, COUNT(*)
from
(
select
customer_id,
row_number() over (partition by customer_id order by service_type_id) rnum,
case
when COUNT(*) over (partition by customer_id) = 2 then 'Mindketto'
when service_type_id = 11 then 'Internet'
when service_type_id = 13 then 'TV'
end szolgaltatas
from Table_1
) cc
where rnum=1
group by cc.szolgaltatasha egy sorba akarod az eredményt akkor viszont ahogy lejjebb írták, (SUM(DECODE...stb)), de a subquery ugyanaz.
-
Petya25
őstag
-
zolynet
veterán
-
Szmeby
tag
válasz
bambano
#2845
üzenetére
A redundancia növeli a biztonságot, az integritást.
Ugyan hibát nem javít, de jelzi, ha teszemazt valaki kézzel belenyúlt és átírt egy összeget (és persze trehány módon elfelejtette átírni a többi hivatkozott összeget is).
Egy "hús-vér" (vagyis papír) számlán is szerepelnek tételesen a részösszegek, és a végösszeg is.
Nem érzem ezt annyira ördögtől valónak. -
jocomen
aktív tag
válasz
bambano
#2838
üzenetére
Köszönöm az észrevételeket, a hibákat javítom. Az "sz.j." mező mit takarna?
#Apollo17hu: Nem tuodm, hogy jó-e, számomra az a fura, hogy a [dijszabas] táblából az összeg nem jelenik meg a [beavatkozas] táblában, a [szamla_tetel] táblában viszont már igen.
Az `osszeg` nem külső kulcs a [szamla_tetel] táblában, ezért nem éreztem úgy, h közvetlen kapcsolat kellene, és oda tettem, ahová leginkább valónak éreztem.A fő problémámra, a kerülő útvonal megszüntetésére akkor nincs senkinek ötlete?
-
Ispy
nagyúr
-
#2749
Sk8erPeter
nagyúr
bambano
#2748
Sk8erPeter
nagyúr
válasz
bambano
#2748
üzenetére
Biztos sok hibalehetőséget rejt magában, amit most nem volt alkalmam normálisan tesztelni, és most gyorsan csak MySQL-lel teszteltem, de ilyen castolás nem jó?
tesztként query (itt implicit castolással):
mysql> SELECT * FROM `mytable` ORDER BY (`number` * 1) ASC, `number` ASC;
+----+-----------+--------+
| id | street_id | number |
+----+-----------+--------+
| 1 | 23 | 4/a |
| 2 | 23 | 5/a |
| 26 | 42 | 11 |
| 5 | 23 | 11 |
| 6 | 23 | 11/a |
| 8 | 23 | 13 |
| 9 | 23 | 13/b |
| 3 | 23 | 14 |
| 4 | 23 | 16 |
| 24 | 46 | 16 |
| 25 | 23 | 18 |
| 7 | 23 | 20 |
| 10 | 23 | 20/a |
| 19 | 23 | 21 |
| 18 | 23 | 38 |
| 23 | 36 | 115 |
| 22 | 36 | 117/a |
| 21 | 36 | 117/b |
| 20 | 36 | 119 |
+----+-----------+--------+
19 rows in set (0.00 sec) -
bpx
őstag
válasz
bambano
#2610
üzenetére
Nem tettem tönkre, ezt egyszerűen így kell leírni, mert sajnos nincs LIMIT. A WHERE előbb van, mint az ORDER BY, a másodikban levő subquery azt jelenti, hogy "olvass fel <4 sort a táblából és rendezd", és nem pedig azt, hogy "kérem rendezés után az első <4 sort".
ez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
Hasonló, de a sorok számára vonatkozó feltételeket speciálisan kezeli, ezek a végrehajtási tervben megjelenő STOPKEY műveletek, amelyek csak addig futtatják a gyerekeiket, amíg el nem érik a megadott limitet. Tehát valóban az történik, hogy úgy kezd neki, mintha az egészet fel kellene olvasni, de 3 sornál megáll. Az adatbázis az egyéb feltételeket is simán mozgatja szintek között, ha szerinte úgy hatékonyabb, azokra nincs külön művelet.
A subquery-t ha lefuttatom magában, nyilván végigmegy 1 millió sorra, hiszen nem lesz ott a külső szűrés, ami leállítja 3 sornál.
-
bpx
őstag
válasz
bambano
#2608
üzenetére
OK, akkor kiegészíteném annyival, hogy Oracle-ben nincs különbség.
SELECT /*+ GATHER_PLAN_STATISTICS */ t.aru_nev, t.aru_egysegar FROM
(SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC)
AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar
Plan hash value: 68470586
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 2 | VIEW | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 3 | WINDOW NOSORT STOPKEY | | 1 | 1000K| 4 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 5 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 1000K| 5 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("T"."SORREND"<4)
3 - filter(RANK() OVER ( ORDER BY INTERNAL_FUNCTION("ARU_EGYSEGAR") DESC )<4)Az első query-t egy az egyben másoltam, a másodiknál a limitet át kellett írnom, mert az itt nincs.
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASC
Plan hash value: 2883829479
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 3 | 3 |00:00:00.01 | 4 |
|* 2 | COUNT STOPKEY | | 1 | | 3 |00:00:00.01 | 4 |
| 3 | VIEW | | 1 | 3 | 3 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 3 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 3 | 3 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(ROWNUM<4)0,01 másodperc, 4 darab blokk érintésével megoldotta mindkettő. Egyedüli látványos különbség, hogy az elsőnél mindenhol 1000K a becsült sorok száma.
A 2 query egyébként nem ekvivalens, rank() helyett row_number()-rel lenne az.
-
bpx
őstag
válasz
bambano
#2605
üzenetére
Window function használatával sem fog a 20 millió rekordon végigmenni, ugyanúgy ki tudja választani index mentén az első 3 darabot, és egy ilyen egyszerű példában nincs különbség.
Ugyanakkor én inkább használnám az egyszerűbb módszert. A window function akkor lenne hasznos igazán, ha lenne PARTITION BY, de nincs. Ezen kívül a becsült kardinalitás a window functionnel sokkal pontatlanabb, így sokkal nagyobb az esély egy kevésbé hatékony végrehajtási tervre.
-
zolynet
veterán
válasz
bambano
#2594
üzenetére
nem megy ez ma nekem, pedig a szándék a fontos
a bonyolultabbhoz nyúltam, de ugye nem arra gondoltam, hanem pl erre:
SELECT aru_nev,aru_egysegar, row_number() over (order by aru_egysegar)
FROM aruka limit 3 részből postgreSql-re gyanakodnék
most mennem kell, majd subquerryvel is megnézem
-
#2499
Sk8erPeter
nagyúr
bambano
#2497
Sk8erPeter
nagyúr
válasz
bambano
#2497
üzenetére
Hopsz, na ez most tényleg az én hülyeségem volt, bevallom, a linkelt hsz. fölött átsiklottam. Nálam már korábban kiakadt a gányolásszenzor.
Szóval innen a félreértés, bocsánat.
Ez esetben már értem a felvetésedet is. 
(#2498) fordfairlane :
Na ja. Engem azért érdekelt volna, vajon akkor pontosan miért is nullázódtak ki az értékei, de úgy látszik, ezt már nem tudjuk meg.
ehh, ott maradt az id az elején, megzavart az anonimizálva 
Új hozzászólás Aktív témák
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- PlayStation 5
- Milyen routert?
- Befutott a régóta várt, sok P-maggal kitömött, LGA1700-as Core sorozat
- Három év után újra előkerült a SiN Reloaded
- Samsung Galaxy Felhasználók OFF topicja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Építő/felújító topik
- Az olcsó Macbook sokkolja a PC-ipart az ASUS társvezetője szerint
- GL.iNet OFF topik
- További aktív témák...
- BESZÁMÍTÁS! Akár részletfizetés 0% THM ÚJ Intel LGA 1700 processzorok 3 év garanciával 27% áfaval
- Xiaomi 11 Lite 5G NE 128GB, Kártyafüggetlen, 1 Év Garanciával
- PCIe 5.0/4.0/3.0 Riser kábelek 90-os hajlított csatlakozóval (220mm/300mm)
- ÁRGARANCIA! Épített KomPhone Ultra 7 265KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- MSI 14 Modern C12M FHD IPS i7-1255U 10mag 16GB 512GB SSD Intel Iris XE Graphics Win11 Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest