Új hozzászólás Aktív témák
-
martonx
veterán
válasz
htcwanted
#3333
üzenetére
Catfathern válasza teljesen jó.
Viszont teljesítményben nem éppen optimális. A MERGE adja a legjobb teljesítményt, viszont azt nem két sor használni, bár nem is olyan vészes.
Hozzáteszem, ha viszont mindig csak új adatot kell hozzáadni, akkor ez nyilván jobb teljesítményt fog hozni, mint egy merge:INSERT tbl_A (col, col2)
SELECT col, col2
FROM tbl_B
WHERE NOT EXISTS (SELECT col FROM tbl_A A2 WHERE A2.col = tbl_B.col); -
martonx
veterán
Szia!
--megkeresed a neked megfelelő collationt
SELECT * FROM sys.fn_helpcollations()
--majd alkalmazod
CREATE DATABASE CaseSensitive
COLLATE SQL_Latin1_General_CP1_CS_AS --így, de ez csak egy példa, ez épp nem a hungarian
select 'a' C union
select 'á' C union
select 'b' C
order by C
select N'a' C union
select N'á' C union
select N'b' C
order by CAmi a sorba rendezős kérdésedet illeti, tudtommal MSSQL-nél ezt így nem tudod megadni. Ha az adat típus varchar, akkor ha a fene fenét eszik is nem unicode rendező algoritmust fog az sql engine rá használni.
Ám ha az adat típus nvarchar (azaz unicode varchar), akkor meg ha a fene fenét eszik is unicode rendező algoritmust fog rá használni.De igaziból lehet, hogy elég a fenti kódrészletem, és a jól beállított collation, és máris jó lesz a sorba rendezés? Vagy a kettő együtt? Lusta voltam kipróbálni, írd majd le a nyerő kombinációt!
-
martonx
veterán
Ez így is van, csak jelzem, hogy éppen a saját ajánlásuk miatt MSSQL-ben a foreign key az automatikusan indexelődik. Meglepődnék ha más SQL-eknél ez nem pont ugyanígy lenne.
Azaz továbbra is fenntartom, hogy manuálisan külön felesleges indexet kreálgatni FK-hoz, ha azt előtte már úgyis automatikusan megcsinálta a db motor. -
-
#3286
martonx
veterán
Peter Kiss
#3285
martonx
veterán
válasz
Peter Kiss
#3285
üzenetére
Azt nem mondtam, hogy nem kell vele dolgozni, de itt sírni sincs értelme, hogy jaj mit tegyek, hiszen csak a létező összes oszlopot össze kell gyűjteni, és ez mind határoz meg egy entitást.
Ezután szépen fel kell tölteni az összes adatot az összes ismert oszloppal, és máris kész a feladat. Hogy közben elröppen pár hónap, kihullik pár megőszült hajszál, az vele jár.
Azt meg ki nem szarja le, hogy végül egy Excelben vagy egy nosql táblában, vagy tsql táblában lesznek tárolva az adatok. Legkézenfekvőbb az excel lenne. -
#3233
martonx
veterán
FIREBLADE78
#3232
martonx
veterán
válasz
FIREBLADE78
#3232
üzenetére
De mit hogyan kell???
Hagyjad, ez így nem fog menni -
martonx
veterán
válasz
kezdosql
#3226
üzenetére
Majd idővel ez a tapasztalat is megérik benned, minden munkánál vannak jelek, amikből könnyű következtetni, hogy van-e értelme foglalkozni a dologgal. Az Acess2000-ről (még most is röhögök ahogy leírtam) szinte már üvölt, hogy kerüld el minél messzebbre azt a céget, aki ezt használja, és nem is hajlandó másra.
-
martonx
veterán
Hopp, és közben meg is csináltam.
Ez lett a végső megoldás:
WITH AreasCTE AS
(
SELECT AreaID, AreaName, ParentAreaID,
cast(AreaName AS varchar(255)) AS AreaPath
FROM dbo.Area
WHERE ParentAreaID is null
UNION ALL
SELECT a.AreaID, a.AreaName, a.ParentAreaID,
cast(s.AreaPath + ' > ' + a.AreaName AS varchar(255)) as AreaPath
FROM Area a
INNER JOIN AreasCTE s ON a.ParentAreaID = s.AreaID
)
SELECT AreaID, AreaPath
FROM AreasCTE ac
ORDER BY 1Viszont a hülye SQL fiddle meghal rajta, miközben lokális SQL szerveren szépen működik, és ez a lényeg.
-
martonx
veterán
Sziasztok,
A probléma szemléltetésére csináltam egy SqlFiddle-t. Csináltam egy rekurzív select-et (ami valószínűleg nem is az igazi), ráadásul nekem nem is ilyen végeredmény kellene, de kiindulásnak talán jó.
Szóval a példában adottak országok, megyék, városok. A példából nekem valami ilyet kellene kihoznom:AreaId, AreaFlow
4, Canada > Saskatchewan > Saskatoon
6, United States > Florida > MiamiMit kellene a rekurzív selectemen módosítani, hogy ezt a kimenetet adja?
-
martonx
veterán
Hát nem SQL-ből
Azaz fogod és írsz egy PowerShell scriptet mondjuk, ami ütemezve fut (Windows scheduler ugye). És a scripten belül azzal kezded, hogy letöltöd a file-t, ha ez sikerült, akkor tovább mész, és üríted a temp táblát bulk insertelsz. Ha ez sikerült, akkor mehet a végleges betöltés. -
martonx
veterán
Mondjuk Microsoft vonalon maradva Visual Studio LightSwitch 2015 (szólok előre, hogy ingyenes). Jobb, mint az Access, mert:
1. bármilyen teljes értékű SQL lehet alatta, mondjuk MS SQL
2. webes kimenetet generál neked, azaz Access el ellentétben bárhol bármikor, akárhány konkurens userrel tudjátok használni.Nem Microsoft vonalon is van egy csomó ehhez hasonló eszköz.
"A táblák megvannak, formok is vannak bevitelhez, egyszerűbb lekérdezésekhez is, csak ez a qrva "excel" nem megy a készlettel."
No ez az, dobd ki az egész eddigit, és írd újra azzal a megközelítéssel, amit fentebb mondtam. Bármilyen eszközzel is fogsz végül nekiállni, amit mondtam mindegyikre igaz lesz. 100%, hogy alapjaiban elhibázott az adat tábla struktúrád, és így nyilván a rájuk épülő formok is. -
martonx
veterán
-
martonx
veterán
Szerintem teljesen rossz az alapállásod a feladathoz. Neked Accessben alap formokat, táblákat kell definiálnod, amiknek közük nincs a fejedben élő Excelhez.
Csinálsz egy formot, ahol bekéred a készlet mozgást, utána pedig Access SQL-el kezeled a többit. Ugyanakkor szólok, hogy szvsz nagyon nem az Access a megfelelő eszköz erre így 2016-ban, bár programozási tudás híján talán mégis (bár még akkor se, bár akkor semmi megoldás sem jó
![;]](//cdn.rios.hu/dl/s/v1.gif)
). -
#3092
martonx
veterán
concret_hp
#3091
martonx
veterán
válasz
concret_hp
#3091
üzenetére
HAVING a kulcsszó
-
martonx
veterán
Nem értettem teljesen a kérdésedet, de valami ilyesmi dinamikus lekérdezést szeretnél?
https://www.mssqltips.com/sqlservertip/1160/execute-dynamic-sql-commands-in-sql-server/
Azaz exec ('select * from table') - ahol a stringed igaziból bármi lehet, azt szépen végig fogja hajtani az sql motor.
-
martonx
veterán
Ehhez group by-t kellene használnod plusz valami aggregátor függvényt (mondjuk count). Példa nélkül ennél konkrétabb segítséget nem fogsz kapni.
Azaz kóddal, meg ciklusokkal, meg ilyesmikkel nem kell bohóckodnod, pusztán az SQL mindezt megcsinálja neked, ráadásul sokkal gyorsabban mintha program kóddal szeded össze az adatokat. -
martonx
veterán
válasz
Jim Tonic
#3033
üzenetére
Szerintem ebben az esetben egy teljesen sima tárolt eljárás lenne a megoldás, persze trigger-rel is meg lehet csinálni csak nem elegáns, a triggereket érdemes kerülni, amennyire lehet.
Azaz a sima insert-ed helyett, amit egy trigger figyel, írsz egy tárolt eljárást, annak átadod a paramétereket, és az magán belül intézi az insert-et, kikeresést, és ha kell a másik táblába insert-et.
-
martonx
veterán
válasz
half333
#3013
üzenetére
Ha 15mb-os, akkor ahonnan kiexportáltad, ott fogod és scriptet generálsz, nem pedig DB Backup-ot csinálsz. A scriptedben nem lesz más, mint a db sémád, és egy rakás insert. Ez se lesz sokkal több, mint 16MB.
Aztán a scriptet fogod és lefuttatod az SQL Server 2014 alatt, és voilá. -
martonx
veterán
válasz
half333
#3008
üzenetére
Bevallom évek óta nem futtatok elvből SQL szervert lokálisan, csak felhőből (esetemben Azure SQL). SSMS-t is csak a melóhelyen használok, kezdek egyre inkább átszokni a Visual Studio Data Tools-ra. De a 2,5 évvel ezelőtti emlékeim szerint az SQL Server 2012 telepítése win8 alá next-next-finish módon ment, szóval nagyon nem értem a problémádat.
Egészen biztos vagyok benne, hogy win10 + SQL Server 2014 (lehet, hogy időközben kijött a 2016 is?) telepítése is next-next-finish bonyolultságú, de most csak a te kedvedért nem fogok magamhoz SQL szervert telepíteni, csak hogy bizonyítsam az igazam.Szóval nem értem milyen megoldást keresel, milyen problémára? Itt van egy mini tutorial, hogy hogy kell kapcsolódnod a szerverhez az SSMS-el: [link]
Szerk: mire megírtam a hosszú hsz-emet, látom sikerült is megoldanod.
-
martonx
veterán
válasz
half333
#3006
üzenetére
SQL 2000 után SQL 2014? Elég erős váltás
Server name-nél alapból nem ír ki az SSMS semmit, mivel hehe, neked kell beírnod, hogy mégis melyik szerverhez szerenél kapcsolódni. Localban ez localhost, vagy csak simán '.'
Utána, amikhez már sikeresen kapcsolódtál, akkor azokat a server name-eket megjegyzi, és alapból be fogja írni neked. -
-
martonx
veterán
válasz
zolynet
#2920
üzenetére
Vagy nekiállnak valamilyen BI rendszert használni. PL. a Microsoft Office-ban lévő Power BI mostanra egészen elképesztő tudású. És még sokba se kerül (relatíve persze), mert az Office árában benne foglaltatik a 2013-as verziótól kezdve. Persze egy ilyen önkiszolgáló BI használata előtt se árt egy pár százezres képzésen részt venni, hogy mégis eszik-e vagy isszák.
-
#2917
martonx
veterán
Apollo17hu
#2916
martonx
veterán
válasz
Apollo17hu
#2916
üzenetére
Ha nincs módja az excellel direktben lekérdezni az adatokat a DB-ből, akkor excel makróval se fogja azt tudni elérni. És ezen még a gugli se fog tudni segíteni neki
-
martonx
veterán
válasz
Agostino
#2913
üzenetére
Jelzem az Excel direktben le tud kérdezni adatbázisokból is, szóval ezt a lekérdezem majd átforgatom excelbe lépést illik tudni megspórolni.
És ha már direktben lekérdez, akkor semmi se tarthat vissza, hogy a lekérdezéseidre beállíts automatikusan frissülő diagram-okat, pivotokat, amit csak akarsz, és voilá. -
martonx
veterán
válasz
Froclee
#2897
üzenetére
Ja vár, elsiklottam a felett, hogy te csak egy darab táblát akarsz backupolni. A backup az a komplett DB backupra jó, bár lehet, hogy meg lehet neki mondani, hogy csak egy táblát akarsz backupolni, még sose próbáltam csak egy táblát backupolni vele.
Másrészt ha ugyanazon DB-n belül akarsz backupolni, akkor miért nem:
insert into backuptabla
select *
from eredetitablavagy select * into backuptabla from eredetitabla
hirtelenjében nem tudom melyik a nyerő szintaxis.
-
martonx
veterán
válasz
Froclee
#2895
üzenetére
1. ne viccelődjünk már, MS SQL-t rohadtul nem generate scripttel kell backupolni, hanem a backupolás funkcióval, ami meglepő módon pont erre van kitalálva. Akár még tömöríti is neked közben az adatot. Tudom durván el van rejtve, a te képernyőmentéseden pl. a totál váratlan Back Up menü pont néven szerepel 5-tel a Generate Script felett.
2. a select count nem erre való, noha rossz gyakorlatként gyakran használják erre. Nálunk pl. a legnagyobb táblában lévő pár milliárd sornál, ha kiadsz egy select count-ot, akkor simán leáll a 64 magos, 256Gb-s szerver is. Ellenben van egy rakás analitikai beépített függvény, simán le tudod kérni az összes tábla adatait. Mondjuk így: [link]
-
martonx
veterán
válasz
half333
#2871
üzenetére
Ja várjál már, ne viccelődjünk. Nem írtad, hogy te eddig SQL 2000-rel szórakoztál, fel se tételeztem, hogy SQL 2005-nél régebbit bárki is használ manapság pár nagybankon kívül (vagy talán már ők sem).
Hát ez zseniális
Miért nem akarsz rögtön clipper-es adatbázist - vagy mi is volt annak idején a dos-os förmedvények alatt - futtatni a 2015 augusztusában kijött win10 alatt?
De hogy konstruktív is legyek, én a helyedben tennék fel egy virtuális gépben windows XP-t, arra simán fel kell tudnia menni az SQL 2000-nek. Más kérdés, hogy jó sok erőforrásba fog kerülni a gépeden csak azért virtuális gépet futtatni, hogy végül azon fusson az SQL 2000, és még jóval lassabb is lesz, mint eddig.
-
#2867
martonx
veterán
BigBlackDog
#2865
martonx
veterán
válasz
BigBlackDog
#2865
üzenetére
Nem az a kérdés, hogy mennyi adatot kellene tárolni NoSql-ben (jelzem havi 100 millió adat nudli, bármelyik TSQL-nek is, már ha nem egy Pentium 4-esen futtatod, 1Gb ram mellett), hanem az a kérdés, hogy milyen komplex lekérdezéseitek, riportjaitok lesznek.
Addig aranyos dolog a NoSql, amíg csak tolja bele az ember az adatokat, de amikor azokat ki is kellene szedni, netán bizonyos relációkat megvalósítani, akkor elég gyorsan ki fog derülni, hogy csodák nincsenek.
Ettől még igenis van létjogosultsága a NoSql-nek bizonyos területeken, csak jelezni akartam, hogy amikor döntötök, akkor több szempontot is vegyetek szemügyre, ne csak a havi 100 millió rekordot, ami egyébként abszolút nem sok, még ha nektek soknak is tűnik elsőre.
Ha meg a hype miatt szeretnétek NoSql-t, akkor érdemes megnézni a NewSql-eket is, mert ez a legújabb hype: [link] -
#2859
martonx
veterán
TomyLeeBoy
#2856
martonx
veterán
válasz
TomyLeeBoy
#2856
üzenetére
Belegondoltál-e már abba, hogy amit szeretnél, azt nem így kellene megoldani? Gondolom PHP-ban ügyködsz, és van egy összekonkatenált sql query-d, aminek a végén mindig ott van ez a where.
De miért van ott, amikor bizonyos esetekben egyszerűen nem kellene, hogy ott legyen? Alakítsd át a kódodat, és ha már átalakítod, akkor a konkatenálást is csináld meg normálisra. -
#2855
martonx
veterán
TomyLeeBoy
#2854
martonx
veterán
válasz
TomyLeeBoy
#2854
üzenetére
szerintem az üres karakterrel ezt fogod elérni, de azért joker karakternek nem nevezném.
-
martonx
veterán
válasz
pityaa23
#2782
üzenetére
Első ránézésre már nem vészes.
Pár észrevétel:
1. a táblád nevei nagyon bénák. Alapanyag, meg alapanyagok? Eleve mindent angolul nevezünk el, a kapcsolat táblákat pedig valahogy úgy illik elnevezni, hogy a nevéből is látszódjon, hogy mit kapcsol össze mivel.
2. Az étkezést tovább bontanám ételekre, mert egy ebéd pl. jó eséllyel áll levesből és főételből.
3. hiányolom a mennyiségi egységet az alapanyagokból. Nem mindegy, hogy 1 liter, vagy 1 kg. -
#2746
martonx
veterán
dellfanboy
#2745
martonx
veterán
válasz
dellfanboy
#2745
üzenetére
where faktor = -1 ?
-
-
martonx
veterán
válasz
DNReNTi
#2697
üzenetére
Igaziból 100K-nyi adat annyira kevés, hogy édesmindegy, hogy melyik verziót választjátok. Ez csak magán vélemény, de az sql adattárolás nem olyan mint egy programkód, azaz ami össze tartozik, és 1 - 1 kapcsolat van közöttük mint esetedben a user neve, jelszava és a user lakcíme, azt semmi értelme csak azért szétbontani, és a másik táblában is elkezdeni egy userID-t vezetgetni, indexelni, meg view-t írni föléjük, hogy mégis egynek látszódjanak stb... mert szeparáljuk minél több, minél kisebb részre az adatokat. Ez SQL adattárolás nem pedig OOP programozás.
És ez nem azt jelenti, hogy ne legyen legalább első normálformára hozva a DB struktúra, csak éppen minek csináljunk felesleges roundtripeket, ha ezek az adatok úgyis összetartoznak.
Persze, hogy ez mennyire eset függő, mert simán tudok magam ellen is érvelni, mikor valakinek több száz Gb-os táblái vannak, és minél jobban partícionálni akarja őket, akkor meg pont az lehet a jó, ha több felé van osztva az adattartalom, mert akkor a cluster több része nagyobb párhuzamossággal tud dolgozni a táblán (mondjuk pár száz millió rekordnál egy rosszul elsült update is ki tudja lockolni az egész táblát), de mondjuk egy szál nagy tábla particionálására is megvannak a módszerek.
Száz szónak is egy a vége, ilyen kevés adatnál teljesen mindegy melyik verziót választjátok, én személy szerint nem kezdeném bonyolítani az egyszerűt.
-
martonx
veterán
Tűrhető. Maga az sql az tök gyors, csak van egy pár másodperces késleltetése. Ami egyébként kb. észrevehetetlen egészen addig, míg a lokális gépedről be nem akarsz insertelni pár száz sort egyenként
Ugye ilyenkor mindegyik inserthez ha számolunk 1-2 mp késleltetést, akkor az 100 insertnél már 100-200mp. Átlag selecteknél, amik az sql-en 0,1mp-ig futnak, felhőből meg mondjuk 1,1mp szerintem ez simán vállalható. Ha meg komolyabb selectet futtatsz, az az 1-2mp tényleg elenyésző - mondjuk 30mp helyett 31.
Szóval vannak olyan speciális esetek, amikor tud fájni, de lássuk be, nem túl gyakori, hogy saját gépről egyenként toljuk be az adat sorokat több száz, több ezer számra.
Az észak-európai központ úgy saccra legalább 1000km-el közelebb van, mint a nyugat-európai (hollandia vs írórszág), így a késleltetése is jobb. -
#2649
martonx
veterán
fordfairlane
#2648
martonx
veterán
válasz
fordfairlane
#2648
üzenetére
Én meg lokálisan nem futtatok DB-t, csak felhőből. Így a 4 fejlesztői gépem között a DB-t legalább nem kell szinkronizálgatni.
-
martonx
veterán
válasz
jocomen
#2567
üzenetére
A join-ok szvsz átláthatóbbak, és talán (ez persze nagyban függ az sql motortól) jobban lehet őket optimalizálni, mint egy rakás where paraméterbe rejtett subquery-t.
Elméletileg az sql motor ugyanazt a végrehajtási tervet kellene, hogy készítse mindkét esetben, gyakorlatilag pici apróságokon is tud múlni, egy - egy sokkal optimálisabb terv felbukkanása. -
martonx
veterán
válasz
DNReNTi
#2540
üzenetére
beleokoskodhatok én is?
Amellett, hogy abszolút egytértek veled, ha már nevezéktanról beszélünk, akkor nem kellene rövidítéseket használni pl. _nm
Még most is gondolkozok rajta, hogy mit jelenthet az az nm? Ráadásul abból, hogy size_and_price bőven látszik, hogy miről is szól az a tábla.
Aztán szerintem az alulvonósdi elég idétlen az SQL nevezéktanokban (html-ben persze tökéletes az alulvonás, de ez most SQL). Miért nem lehet simán SizeAndPrice-nak hívni a táblát? Ez totál szubjektív, de szerintem sokkal szebb felesleges alulvonások nélkül. -
#2486
martonx
veterán
PumpkinSeed
#2483
martonx
veterán
válasz
PumpkinSeed
#2483
üzenetére
Hehe, így legyen 5-ösöm a lottón. Mondtam én, hogy a kódoddal lesz a hiba.
-
#2478
martonx
veterán
PumpkinSeed
#2477
martonx
veterán
válasz
PumpkinSeed
#2477
üzenetére
Most komolyan erre mit mondjunk? Vagy a kódódban van valami hiba, vagy a mysql-ed valami elavult verzió, ami ráadásul egy roncs instbil gépen fut. Vagy mindkettő. Nyilván normális esetben ez lehetetlen lenne.
Én egyébként ismerve a hszeidet, biztosra veszem, hogy a kódodban lesz a hiba, és nem a mysql-ben. De egy Pentium 3-ason futó MySql-től is kitelhet bármi. -
#2388
martonx
veterán
Apollo17hu
#2387
martonx
veterán
válasz
Apollo17hu
#2387
üzenetére
Ez egy fokkal szebb megoldás az általam javasoltnál
-
martonx
veterán
válasz
bambano
#2385
üzenetére
A sorokat össze tudod húzni persze. Mondjuk minden sornak te adsz egy növekvő azonosítót (MSSQL-ben ez a RANK), és ez az azonosító alapján joinolod össze a táblát saját magával eggyel elcsúsztatva egymáshoz képest.
Ezután a dátumok kivonása már gyerekjáték, azt meg nem írtad, hogy hogy akarod súlyozni a végeredményt, de szerintem minden adott a feladatod megoldásához. -
#2280
martonx
veterán
PumpkinSeed
#2277
martonx
veterán
válasz
PumpkinSeed
#2277
üzenetére
Sémákkal tudsz adatbázisokat / adatbázis részeklet elkülöníteni. Olyan ez, mint programozásban a namespace.
Sequence: már a nevében benne van, hogy mi ez, és mire jó. Nem fogod kitalálni, egy folyamatosan növekvő számláló. Hogy mire jó azt a képzeletedre bízom, pl. adatbázis sorokat azonosítani.
-
#2240
martonx
veterán
PumpkinSeed
#2239
martonx
veterán
válasz
PumpkinSeed
#2239
üzenetére
Van két adathalmazod. Az egyik SQL táblában, a másik meg egy szöveg fileban mondjuk vesszővel elválasztva.
Mit teszel, ha a kettő közös metszetét kellene meghatároznod?
Persze elkezdheted mindkettőt lekérni, majd memóriában for-okkal összeforgatni, és ifekkel ellenőrizni.
Vagy fogod, feltöltöd a csv-det egy ilyen external táblába, és egy szimpla sql select-el megkapod a közös halmazt.
Kapisgálod, hogy mire jó ez? -
#2213
martonx
veterán
Apollo17hu
#2211
martonx
veterán
válasz
Apollo17hu
#2211
üzenetére
Esetleg ha sqlfiddle-re tennél fel példát, akkor el is tudnánk mélyedni benne az ötletelés helyett.
-
#2212
martonx
veterán
Apollo17hu
#2207
martonx
veterán
válasz
Apollo17hu
#2207
üzenetére
Jobbnak nem jobb, csak leírva rövidebb, mint egy jó hosszú case when.
-
#2206
martonx
veterán
Apollo17hu
#2203
martonx
veterán
válasz
Apollo17hu
#2203
üzenetére
A case when helyett coalesce-et használnék
-
#2192
martonx
veterán
kemkriszt98
#2190
martonx
veterán
válasz
kemkriszt98
#2190
üzenetére
Milyen SQL?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Dell Alienware AW2521HFLA 25" 240Hz Gamer Monitor 27% ÁFÁS - 0248BE
- Akció!!! Sosemhasznált! HP OmniBook 5 i7-1355U 16GB 512GB 16" FHD+ Gar.: 1 év
- Akciós kisWorkstation! Dell Precision 3560 i7-1165G7 4.7GHz / 32GB / 512GB / Quadro T500 2GB FHD 15"
- Értékcsökkentett gamer alaplapok /ASUS/MSI/AM5/Számlával/
- DTK 2.1 Multimedia Speaker System 3D-168D
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest