Új hozzászólás Aktív témák
-
Apollo17hu
őstag
válasz don_peter #1698 üzenetére
Ha topikonként a legfrissebb bejegyzésre van szükséged, akkor valahogy így kellene:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.titleEz mondjuk nem MySQL, de a kétszeri sorbarendezést (ORDER BY) kiváltja egy aggregáló függvény, ami valószínűleg gyorsít rajta.
[ Szerkesztve ]
-
don_peter
senior tag
válasz Apollo17hu #1704 üzenetére
Köszönöm, ez így 3.8-4mp-ről 0.18-0.22mp-re csökkentette a lekérdezési időt.
A csoportosítást lehet még tovább bonyolítani?
Ha mondjuk még kíváncsi lennék a bejegyzést készítő felhasználó nevére?----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz don_peter #1705 üzenetére
Gondolok itt ilyesmire:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum,
u.nick AS nev
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id AND u.id = fu.user_id
GROUP BY t.id,
t.title
u.id
ORDER BY `updatum` DESC LIMIT 8Vagy ezt tovább már nem lehet feszegetni?
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
Apollo17hu
őstag
válasz don_peter #1706 üzenetére
MySQL tud analitikus függvényeket? Ha igen, akkor én valahogy így csinálnám:
SELECT x.*
FROM (SELECT t.id AS tid,
t.title AS title,
fu.datum AS updatum,
u.nick AS nev
rank() OVER (PARTITION BY t.id ORDER BY fu.datum DESC) AS sorrend
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id) AS x
WHERE x.sorrend = 1Amúgy az a nyolcas limit mi akar lenni a lekérdezéseidben?
[ Szerkesztve ]
-
don_peter
senior tag
válasz Apollo17hu #1707 üzenetére
A limit 8 azt jelenti, hogy csak 8 record-ot kérjen le. Esetünkben a 8 legfrissebbet.
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz Apollo17hu #1707 üzenetére
Ezt a nyelvet már nem ismeri.
Legalább is ebben a formában.
Köszi azért, el voltam vele kicsit----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
fordfairlane
veterán
válasz Apollo17hu #1707 üzenetére
MySQL tud analitikus függvényeket?
Tudomásom szerint egyiket sem ismeri.
x gon' give it to ya
-
Apollo17hu
őstag
-
don_peter
senior tag
válasz Apollo17hu #1712 üzenetére
Makszimum 8 topik jelenik meg az utolsó bejegyzések alapján csökkenő sorban.
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz Apollo17hu #1712 üzenetére
Igen az nem jó, ezt én is tudom ezen tovább is léptem már.
Most már az egész lekérdezést nézem nem csak részleteket.
Sok a subselect és ez megnehezíti a lekérdezést.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
Apollo17hu
őstag
válasz don_peter #1714 üzenetére
Akkor két allekérdezés kell:
- az egyikben listázod topikonként a legfrissebb hsz.-ek dátumát,
- a másikban pedig leszeded topikonként a userek legfrissebb hsz.-eit.Ezt a kettőt topik-topik és dátum-dátum kötéssel kötve ezt kapod:
SELECT topik_datum.title,
topik_user_datum.nev,
topik_datum.updatum
FROM (SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.title) AS topik_datum,
(SELECT t.id AS tid,
u.nick AS nev,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id
GROUP BY t.id,
u.id) AS topik_user_datum
WHERE topik_datum.tid = topik_user_datum.tid
AND topik_datum.updatum = topik_user_datum.updatum
ORDER BY topik_datum.updatum DESC LIMIT 8Hogy milyen gyorsan fut le, az jó kérdés, de analitikus függvények nélkül ennél jobbat nem tudok.
[ Szerkesztve ]
-
don_peter
senior tag
válasz Apollo17hu #1715 üzenetére
Bár a lekérdezésed lefut és majdnem jó is csak valamiért szelektál.
Nem az összes bejegyzést figyeli.Most ezt írtam és használom ez jól működik, legalább is úgy tűnik:
SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESC LIMIT 8----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
TomyLeeBoy
tag
Üdv mindenki!
Egy mysql lekérésem nem futott le végig, úgy éreztem kimaradnak elemek, így elkezdtem utána járni a dolognak és a következő lett a megoldás:
Az egyik rekord VARCHAR típusú, 50 hosszú mezőjében a következő érték van: M01535/2015/004723
Ennél a rekordnál meghal a lekérdezés. Ha bármi mást írok a helyére akkor szépen lefut. Nem értem mi ebben a speciális tartalom hogy ez miatt nem megy. Másik rekordnak ugyanebben az elemében is vannak / jelek és azzal semmi gond.
Ha tudnám hogy mi a baja ezzel, csinálnék valami védelmet hogy ne lehessen olyat beírni amitől nem fog működni a lekérdezés, de nem tudok rájönni ezzel mi a gond.A lekérdezés:
SELECT * FROM tabla WHERE YEAR(date) = '2015' AND MONTH(date) = '5' AND sum='1' ORDER BY date DESCés php-ban while-al járom végig.
Ha valakinek van ötlete nagyon megköszönném.
Az idő sebessége: 1s/s
-
sonar
addikt
válasz TomyLeeBoy #1718 üzenetére
Szerintem a php-vel van a baj, mert escape karakternek érzékeli.
Nézz utána a stripslashes() függvénynek.A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
TomyLeeBoy
tag
Valóban a php-ben volt a hiba de nem a / miatt, további string manipuláció közben volt probléma amit semmi nem érzékelt hibának, igy nem volt semmi hibaüzenet, mégis elhalasztotta a scriptet, és furcsa módon csak ennél a változónál jött elő.. Köszi az ötleteket azért
Az idő sebessége: 1s/s
-
fordfairlane
veterán
válasz TomyLeeBoy #1721 üzenetére
A / max regexp patterdefinícióknál okozhat gondot, sehol máshol. Elég elcseszett sztringkezelés lehetett abban a scriptben.
x gon' give it to ya
-
don_peter
senior tag
Srácok van egy ilyen lekérdezésem:
SELECT * FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESCA kód hibája az, hogy ha nincs bejegyzés egy meglévő topikban, akkor azt nem listázza ki.
Tudom, hogy itt a hozzászólásokhoz van csatolva a dolog, de miképpen tudom ezt úgy megoldani, hogy azt a topikot is listázza amelyikben még nincs bejegyzés?
Természetesen azt a végére kell kilistáznia.Erre a részre, ha beteszek egy ilyet:
ON t.id = fu.topik_id or t.id
Akkor listázza, de az első helyen és belassítja kb. 10szeresen a lefutási időt.
Ráadásul nem is jó így...Előre is köszönöm.
[ Szerkesztve ]
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
Apollo17hu
őstag
Ha van UNION utasítás MySQL-ben, akkor megoldás lehet, hogy összefűzöd egy olyan lekérdezéssel, amiben minden topik szerepel, de mondjuk 999999-es id-val (amit konstansként adsz meg).
Vagy átírod az egészet úgy, hogy a topikhoz kötöd gyengén a dolgokat, nem pedig azt kötöd gyengén a hsz.-ekhez.
-
don_peter
senior tag
válasz Apollo17hu #1724 üzenetére
Van UNION..
Utána nézek...
Ha van egy megoldásod, akkor az is jöhet..
Köszi..----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
Apollo17hu
őstag
válasz don_peter #1725 üzenetére
Az előbb lehet, hogy részben hülyeséget írtam, de valahogy így gondoltam:
SELECT c.* FROM
((SELECT a.id, a.title, a.datum, a.nick FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) AS a
GROUP BY a.id) b
UNION
(SELECT t.id, t.title, 1000-01-01 as datum, NULL as nick FROM topik t) seged) c
GROUP BY c.id
ORDER BY c.datum DESC...tehát minden topikhoz létrehozol egy 1000-01-01 dátumra vonatkozó hsz.-t, ami csak akkor számít a sorrendben, ha nincs rajta kívül más hsz. (tehát ha üres a fórumtéma).
[ Szerkesztve ]
-
don_peter
senior tag
válasz Apollo17hu #1726 üzenetére
Ez sajnos nem fut le, de értem a gondolat meneted..
Próbálkozom, hátha tudom javítani a kódot.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz don_peter #1727 üzenetére
Nos kicsi átalakítással már működik is és elég gyors 0.1mp-es lefutási időt produkál.
SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) as a
GROUP BY a.id
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick FROM topik t where t.topik_csoport_id = 9) c
GROUP BY id ORDER BY datum DESCKöszi a segítséget és az elvi rávezetést...
ui: öhh, még sem jó..
Nem jól szelektálja az utolsó bejegyzéseket.
Ennek még utána nézek..[ Szerkesztve ]
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
don_peter
senior tag
válasz don_peter #1728 üzenetére
No ez már jó
Hátha tudok vele segíteni...
Aki tud ennél egyszerűbb megoldást az kérem ossza meg velem.
Köszönöm.SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick
FROM topik t
where t.topik_csoport_id = 9
) c
GROUP BY id ORDER BY datum DESC----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
bpx
őstag
válasz don_peter #1729 üzenetére
Ha azok a topikok kellenek, amelyekben nincs hozzászólás, akkor miért a forum_uzenetek van a LEFT JOIN bal oldalán?
forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.idEz azt jelenti, hogy azokat fórum üzeneteket is kéred, amelyek egyik topikhoz sem tartoznak.
forum_uzenetek LEFT JOIN topik + UNION bonyolítás helyett nem egyszerűbb lenne a topik LEFT JOIN forum_uzenetek?
[ Szerkesztve ]
-
don_peter
senior tag
A fenében
Totálisan igazad van, kezdek megvakulni..
Gondolom most már az lehet a baj, hogy egy hete folyamatában megállás nélkül írom az új kódokat és már kezdek belefáradni.A leegyszerűsített kód ami működik:
SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM topik t
LEFT JOIN forum_uzenetek fu
ON fu.topik_id = t.id
LEFT JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESCGondolom erre gondoltál te is...
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
bpx
őstag
válasz don_peter #1731 üzenetére
Feltételeztem, hogy olyan eset nem fordul elő, hogy egy fórum üzenethez nem létezik user (mert usert általában nem törlünk, csak inaktiválunk), és így nem kell ezek közé is outer join, de egyébként igen.
Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)
MySQL-ben sajnos nincsenek analitikus függvények, helyette vannak ilyen kerülő megoldások:
Végül limitálni kellene, hogy hány sort kapunk vissza, hogy ne dolgozzon esetleg feleslegesen az adatbázis, és gondolom a felhasználónak sem a létező összes, akár több száz, ezer topikot rakod ki felületre, hanem csak egy fix mennyiséget, ahogy pl. itt a prohardveren is működik.
[ Szerkesztve ]
-
don_peter
senior tag
User mindig létezik, ha már készült bejegyzése, más módon inaktiválódik..
Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)
Erre egy példát tudnál készíteni nekem?
A topikok összességét nem limitálom, de gondolom, ha eljön az ideje azt is meg fogom oldani, bár még egyelőre nincs elképzelésem hogyan..
Itt tudod megnézni miről is van szó: [link]A fórum bejegyzések limitálva vannak termesztésen, maximum 20db van 1 lapon...
[ Szerkesztve ]
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
MineFox54
őstag
Sziasztok! Az kéne, hogy ki kéne listáznom az 5 legnagyobbat, egy int alapján.
Tehát:
Id name orderbythis
1 john. 34
2 peter. 23
3 sarah. 47
Stb.A táblából azt az x rekordot kell kiválasztani, ahol az orderby a legnagyobb.
Hogy, s mint csináljam?
-
sonar
addikt
A lenti query-vel van egy olyan problémám, hogy ha ez a két feltétel benne van a select-ben
e.port_speed !='null' and e.port_speed != 'N/A'
akkor az insert elszáll az alábbi hibakóddal
Error Code: 1292. Truncated incorrect DOUBLE value: 'null'Nem értem, hogy mi a baja, pont azért akarom kiszűrni a null-t és az N/A-t, hogy hülyeség ne kerüljön be az adatbázisba.
insert into tbl_port_summary (port_id,summa,speed_1000M,speed_100M,speed_10M)
SELECT e.port_id, count(*) as Ossz, sum(if (e.port_speed='1000',1,0)) as Speed_1000M,
sum(if (e.port_speed='100',1,0)) as Speed_100M,sum(if (e.port_speed='10',1,0)) as Speed_10M
FROM tbl_log_011 as e
where e.port_speed !='null' and e.port_speed != 'N/A'
and e.timestamp > 1434326400
group by e.port_id order by e.port_id,e.timestamp;A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
-
MineFox54
őstag
Sziasztok!
Ezzel mi baja van?
UPDATE reg SET `tav'='$tav', 'gender'='$gender', 'birthday'='$birthday', 'name'='$name', 'email'='$email', 'varos'='$varos', 'utca'='$utca', 'focinev'='$focinev', 'telefonszam'='$telefon', 'szamla'='$szamla', 'egyesulet'='$egyesulet' WHERE email='$email'ezt php-ben feltöltöm adatokkal:
Error: UPDATE reg SET `tav'='kerekpar21', 'gender'='ferfi', 'birthday'='xxxxxxxx', 'name'='Somogyi Soma', 'email'='sskss73@gmail.com', 'varos'='xxxxxxx', 'utca'='xxxxxxxxxx', 'focinev'='-', 'telefonszam'='xxxxxxx', 'szamla'='-', 'egyesulet'='-' WHERE email='xxxxxxxxx'
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 -
sonar
addikt
válasz MineFox54 #1742 üzenetére
Próbáld meg így:
UPDATE reg SET tav='kerekpar21', gender='ferfi', birthday='xxxxxxxx', name='Somogyi Soma', email='sskss73@gmail.com', varos='xxxxxxx',
utca='xxxxxxxxxx', focinev='-', telefonszam='xxxxxxx', szamla='-', egyesulet='-' WHERE email='xxxxxxxxx';A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
qfm
senior tag
Sziasztok!
Lehet nem jó helyen próbálkozok ezzel, de hátha van közöttetek olyan aki tud rá válaszolni. A mai modern cpu-k közül, minimálisan milyen lenne szükséges ahhoz, hogy egy LAMP szerver másodpercenként 400 selectet, és 100 updatet kiszolgáljon? A selectek nem tartalmaznak joint, és bonyolult műveleteket. A tábla amin updatelni kell, és a selectek fele fut, pusztán 500 rekordot fog tartalmazni, a selectek másik fele, egy nagyjából 2000 rekordot tartalmazó táblán fog futni. Érzésem szerint ezek nem magas elvárások, és akár egy 2 magos pentium is elbírná 4gb rammal, de inkább rákérdeznék nálatok. A webserver nem lesz leterhelve, másodpercenként maximum 250 hívást kaphat, ami egy viszonylag rövid script segítségével 1 karakteres outputot állít elő (az sql műveletek mellett, amit fentebb írtam).
-
martonx
veterán
Szia!
Előre bocsátom, hogy semmi háttérinfóm nincs, így lehet, hogy az alábbiak csak okoskodásnak fognak hatni. Észrevételeim:
1. Ehhez a feladathoz ha jól tippelem ramból kb. semennyi nem kell, a 4Gb abszolút feleslegesen felülméretezettnek tűnik egy pár tíz Mbyte-os adatbázishoz. Cakkumpakk be fog férni a komplett adatbázis a memóriába.
2. CPU-ból egy négy magos vígan ki kellene, hogy tudja szolgálni mindezt. A Pentium necces lehet, és mi van például, ha megduplázódik a terhelés? Akár csak percekre?
3. Pont a fentiek miatt, ma már senki nem gondolkozik saját vas beszerzésében, hanem sokkal érdemesebb szervert bérelni valahol, leginkább mondjuk a felhőben. Így kb. egy csúszka arrébb tolásával meg tudod többszörözni az erőforrásokat, ha épp arra van szükség.
4. Nem vagyok egy nagy NoSQL rajongó, de ez tipikusan olyanfeladatnak tűnik, ahol teljesen felesleges tranzakciós SQL-t használni, egy NoSql sokkal kevesebb erőforrás használatával, sokkal nagyobb teljesítményt tudna elérni.
5. Másrészt megfontolandó, hogy tényleg jól van felépítve az adatbázisotok? Lehet, hogy nem a NoSQL a megoldás, csak alapból szar az SQL-etek architektúrája?
6. Nekem gyanús a backendetek is. Ahogy írod elég faéknek tűnik, mégis miért van szükség egy minimális adat kimenethez több SQL query-re? Lehet érdemes lenne tárolt eljárást írnotok, sql view-t használnotok, php oldalon optimalizálni a kódon, cache-elést bevezetni stb...Én kérek elnézést!
-
sonar
addikt
Én is osztom martonx véleményét, de minden project így indul, hogy csak pár rekord...
Manapság a HW ára és egy migrálással / költöztetéssel eltöltött idő ára nincs arányban.
Nem tudom milyen volumenü a project, de P4 -es pentiumot alapból vágnám ki a kukába ha komoly dologról van szó. 10 éves géppel ne szórakozzunk már...A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
qfm
senior tag
Igazából a leírtak 90%-a nem valódi honlap lesz, hanem eszközök közötti kommunikációra szolgál. Emberek által látott felület minimális lesz. A rekordok száma esetén a maximálisat írtam le, amit a kiépítés megkívánhat. Pentium alatt egy modern G3220-ra gondoltam, nem egy P4-re, de valóban nem definiáltam. Ennek ellenére i3 alatti gépet nem fogok javasolni, csak érdekel mennyire lövök túl a célon. A dedikált hardver külön elvárás volt.
(#1746) martonx
1, A 4gb-os ram nem kifejezetten drága, így csak megnyugtat a tudat, hogy szerinted is bőségesen elég.
2, A forgalom csak akkor ugorhat meg, ha valamelyik hardver meghibásodik, eléggé jól leszűrt forgalom van rá tervezve.
3, A dedikált szerver külön kérés volt, én is mást ajánlottam, de bizonyos okok miatt ez volt a kérés.
4, Soha nem használtam még NoSQL-t, de utána fogok nézni a javaslatodnak.
5, A számok azért ilyen alacsonyak, és talán furák is, mert egy speciális hardver kommunikációhoz lesz csak háttér adatbázis. Az adatmennyiség limitált amit tárolni, és feldolgozni kell.
6, Valóban nagyon egyszerű, és a kimenet előállításához nem is szükséges több sql művelet. A bemenet függvényében azonban több különböző folyamat zajlik le, van amelyik 1 hívással jár, van amelyik 3-al. A legrosszabb esetet vettem alapul. A kimenet pusztán nyugtázó funkciót lát el.+1 a 6-osból adódna a kérdés, hogy miért nem az adatbázist használják a hardverek, hanem a köztes PHP oldalt. Azért mert ez volt az igény.
-
MineFox54
őstag
Sziasztok!
Át kellett vinnem egyik (döglött) gépről a másikra a mysql fájlokat, viszont ezt csak fájlrendszeri szinten tudtam megtenni (kimásolom, új gépen bemásolom). Két DB-nél működik is ez, viszont a harmadiknál nem látja az amúgy ottlévő frm fájlokat. Mit kéne tennem?
Új hozzászólás Aktív témák
- AKCIÓ Új Dobozos Macbook Pro dokkoló új ára 70.000 forint
- ThinkPad Hybrid USB -C USB -A Dock 40AF Új ára 80.000 Forint Ingyen szállítás
- Xiaomi Redmi Note 9s 128/6 GB 34.9E !!!
- Új Hp Pavilion 15-eh Fémházas Szuper Laptop 15,6" -30% AMD Ryzen 7 5700U 8Mag 16/1TB FHD MATT
- ATI RADEON RX 480 -8 gb DDR5 256 bit videokártya