- Az Euronics is elkezd használt mobilokkal foglalkozni
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Xiaomi 15 - kicsi telefon nagy energiával
- Keretmentesít a Galaxy S25 FE
- Samsung Galaxy Watch6 Classic - tekerd!
- Samsung Galaxy A52s 5G - jó S-tehetség
- iPhone topik
- Xiaomi 15 Ultra - kamera, telefon
- Hammer 6 LTE - ne butáskodj!
- Magisk
Új hozzászólás Aktív témák
-
bambano
titán
Ha fafejség ellen kell harcolni, arra a nézettábla megoldás.
Itt az az érdekes helyzet van, hogy a nézettábla két irányból is alkalmazható:
1. van egy pocsék tárolási struktúrád, és abból akarsz jó nézetet generálni.
2. csinálsz egy rendes tárolási struktúrát és abból generálsz pocsék nézetet.Én azt javaslom, hogy minél előbb át kell térni a rendes megoldásra, vagyis 2.
Tehát megcsinálod a 3 táblát, elkezded abba tölteni az adatokat, akár visszamenőleg is, és ráhúzol annyi nézetet, amennyi az aktuális helyzetben kell. Ráadásul nézetet ráhúzni és eldobni sokkal egyszerűbb, mint alaptáblát módosítani. Megcsinálod, hogy azok a programok, amik a rossz struktúrát használják, használják a nézettáblákat, amiket meg ezután módosítotok, már az új megoldást használják.
szerk: ha minden szenzor egy tábla rendszerben tárolod az adatokat és egy nézettáblába hozod össze a sok táblát, akkor ott problémás lehet, hogy egy új szenzor hozzáadásakor megcsinálod a szenzor saját tábláját, és amikor a nézettáblát módosítod, akkor le kell bontani a korábbi nézettáblát és feltenni az újat. Ha pedig minden szenzor egy tábla rendszer van, akkor az új nézettábla létrehozása nem befolyásolja a többi működését.
Itt kerül elő az alapkérdés, hogy milyen a kapcsolat a fafejűekkel, hogy nekik mi mindenről van döntési joguk és mi mindent kell tudniuk. Én csendben átírnám, oszt jónapot.
-
bambano
titán
"Valóban a mérő azonosító karaktereiben lehet betű is.": majd valami agyhalott kitalálja, hogy legyen benne ékezetes betű, pl. tulaj neve vagy címe rövidítve, esetleg bugos utf8 konverter az adatbáziskezelőben (mint ma a debianban...
) és akkor lefekszik az egész....Egyébként a számmal is az a gond, hogyha nem tudod a határait, nem biztos, hogy találsz hozzá természetes adattípust. Akkor eltárolod stringként, és vége. Vagy jöhet olyan történet is, mint egyszeri lakcímnél, hogy beépítenek egy telket, és hirtelen a természetes szám házszámból lesz egy /b.
Soha nem tudhatod, hogy egy architect miket képes elbarkácsolni
-
bambano
titán
Én is közüzemi cég szerűséget találgatok...
Szerintem a mérőket ki kell venni, mert stringek között keresni rosszabb, mint egész számok között, másrészt nem tudni, melyik mérő neve milyen hosszú.Archiváláson valóban érdemes gondolkodni, de a kötelező megőrzési idő, szerintem, elég nagy ahhoz, hogy archiválástól függetlenül meg lehet borítani a lekérdezéseket. Ha a jelentési teljesítmény nem jó, akkor nem jól tervezték meg az adatbázist.
Egyébként a nagy tábla a biztonsági mentéseket borítja meg leghamarabb...
-
bambano
titán
válasz
martonx
#6004
üzenetére
Én úgy értettem abból, amit írt, hogy össze akarja kötni az azonos időben különböző mérőkkel mért értékeket, és ezt nem lehet időbélyeg alapján, mert az mindig változik.
Tehát ha valamiféle egységben (gazdasági egység, megrendelő, számlázási egység) több mérő van, tudni akarja az egy időpontban mért értékeket. Találgatás: például nálam 5 hőmennyiség mérő van, ha simán leszeded a mért értékeket, különbözik az időpont, de bizonyos célokra tudni kell, hogy amikor az egyik mért valamit, pontosan akkor mit mért a másik. -
bambano
titán
Felveszel két táblát, index mezőnek (nem tudom, hogy hívják pontosan). Az egyikbe belerakod a mérőpontok adatait:
id, mérőpont neve, egyéb adata (pl. gázt, villanyt, mit mér).
A másikba leltározod a méréseket: id, dátum, egyéb adatok.Ezután csinálsz egy táblát, aminek van saját id-je, belerakod a mérés indextáblából az id mezőt, a mérőpont azonosítóját, esetleg az aktuális dátumot defaultnak, illetve a mért adatot.
Ez három tábla, nem 500. Lesz egy rakás szkripted, ami összegyűjti a mérési adatokat. Amikor egy ilyen szkript elindul, belerak egy rekordot a mérések leltártáblájába, és visszakapja az id-t. Amikor összeszedi a mérőpontok adatait, akkor ezt az id-t is belerakja a mért adat táblába, és ezzel az id-vel lehet összekötni az egyidejű méréseket.
Egy Chomsky nevű fickó írásait kellene olvasgatnia mindenkinek nálatok.
-
bambano
titán
Ha össze akarod kapcsolni a méréseket, akkor azt kell csinálni, hogy a mérés konkrét dátuma mellett egy azonosító sorszámot is leraksz a táblába, és azzal joinolsz, nem a dátummal. Persze lehetne olyat is, hogy az a program, ami a mérést végzi, lekér egy dátumot, amikor indul, és utána az összes mérési adatot azzal a dátummal teszi le.
Azt látom abból, amit leírtál, hogy nagyon erősen javasolt lenne nulláról újraterveztetni az egészet egy szakértővel. Az, hogy 500 darab azonos tábla legyen egy adatbázisban, az abszolút nonszensz.
"A View egyébként mindig a tartalmazza az összes adatot, azaz magától frissül?": a view, magyarul nézettábla *NEM LÉTEZIK*. Az egy definíció, ami leírja, hogy a tárolási sémából hogyan kell előállítani a nézettáblát. A lekérdezéskor számolódik ki. A magától frissül kérdés értelmetlen. Azt az adatot tartalmazza, amit megadsz neki, hogy tartalmazzon.
-
bambano
titán
Ezt biztosan nem csinálnám, mert ebből orbitális katyvasz lesz a végén.
Ha mindenáron ilyen elhibázott adatszerkezetet kell csinálni, akkor valami szabályrendszert csinálnék (fogalmam sincs, hogy a mariadb vagy a mysql tud-e ilyet, a postgresql tud), hogy ha insert történik az egyedi táblába, akkor párhuzamosan legyen egy insert az összesített táblába is. Ekkor normális adatbáziskezelő egy tranzakción belül elvégzi a két insertet és van rá reális esély, hogy nem szalad szét a két tábla.Továbbra is erőltetném azt az alapelvet, hogy adatbáziskezelésnél a redundancia rossz, menekülünk tőle, mint ördög a tömjénfüsttől.
-
bambano
titán
válasz
kw3v865
#5975
üzenetére
Egyrészt lehet tranzakcióval szeparálni.
Másrészt csinálhatsz verziózott adatokat.
Hozzáadsz egy verzió mezőt, minden adatbetöltésnél egy új verziószámot írsz bele, és a tranzakció végén inkrementálod az aktuális verzió mezőt.Tudomásom szerint a postgresnek nincs in-memory táblája, ramdiszkre lehet tablespace-t rakni.
Vagy erre a táblára használhatsz másik adatbáziskezelőt, ami erre van optimalizálva.
-
bambano
titán
válasz
shipfolt
#5959
üzenetére
ID
Elozo_id
megnevezés
leiras
hatarido
lezart?nem kell két különböző sort egy rekordba rakni. a rekord szerkezet az adatod szerkezetével kell megegyezzen.
Ha elkezded bontani a feladatot, berakod a fő feladatot a táblázatba, megjegyzed az id-jét, és amikor a fő feladat alfeladatait rakod bele, akkor az elozo_id mezőbe beleírod a megjegyzett id-t.
Amikor le akarod zárni a feladatot, akkor meg kell nézni, hogy az a feladat, amelyik az elozo_id-ben van, le van-e zárva.
Szerintem trigger erre felesleges.
-
-
bambano
titán
egyébként a PostgreSQL úgy alakult ki anno, hogy az Ingresből fejlesztették tovább, Postgres néven. Amikor a korábbi lekérdező nyelvét lecserélték szabvány sql-re, akkor átnevezték a projektet Postgresql-re és maradt a rövid neve postgres.
A Postgre az nem hivatalos neve.
-
bambano
titán
én is megcsináltam, még éjjel
with naptar as (
select napok,
(case when date_part('dow',napok) between 1 and 5 then 1 else 0 end)::integer
*
(case when calendar.date is null then 1 else 0 end)::integer as isworkday
from
generate_series(now()::date,now()::date+'60 days'::interval,'1 day'::interval) as napok
left outer join
calendar on napok=calendar.date)
select napok::date,-1+sum(isworkday) over (order by napok) as workdays
from naptar where isworkday=1;kb. ennyi az alap, ebből lehet közvetlen lekérdezést csinálni vagy window funkcióval és rownumberrel, vagy én csináltam belőle egy view-t és abból közvetlenül lehet selectelni.
egy rakás lehetséges optimalizáció még van benne, például a két case helyett lehetne egyet, stb.
-
bambano
titán
"A számítógépet logikus dolgokra lehet programozni. Előre nem ismerhető szeszélyek meghatározására nem alkalmas.": próbáljunk meg az sql témakörben maradni.
Az algoritmus abszolút egyszerű: van egy tábla az adatbázisban, ahova a főnök beírja azokat a napokat, amikor valamiért nem az alapértelmezett nyitvatartás van. Ezt törvény szerint 60 nappal előre kell megoldani, tehát nem mindig írják bele egy évre előre. A szabály annyi, hogy ha ebben a táblában van az adott dátumra rendkívüli nyitvatartás bejegyezve, akkor az nem munkanap. Minek bonyolítsam. Amikor naptár szerint hétfő-péntek munkanap és nincs rekord arra a dátumra, az munkanap.
-
bambano
titán
"Ha adatkezeléssel foglalkozol, nem baj, ha nem akadsz ki azon, hogy gyártani kell pár táblát, amit fel is kell töltened.": ha adatkezeléssel foglalkozol, nem baj, ha nem csinálsz felesleges munkát magadnak.
2. Ha adatkezeléssel foglalkozol, akkor a redundáns adattárolástól üvöltve menekülsz.
Szerk: nem csak az a nap marad ki, amit a hr portálon közölnek. Az is kimarad, ami helyi okokból nem munkanap vagy nem teljesértékű munkanap. Pl. egy rakás cégnél karácsony és szilveszter között takarékon vannak.
-
bambano
titán
akkor fejlesztenetek kell
szerintem ez sem jó.
például idén dec. 20-án ki akarok adni egy 15 napos határidőt, kijön január 4, szombat, lépek tovább, január 6. hétfő az első munkanap.
Csak közben volt egy 6 napos karácsony meg egy szilveszter, és ez így pont 4 munkanap lesz. -
bambano
titán
válasz
#79484416
#5880
üzenetére
Melyik határidőt? Ez így azért nem jó, mert az, hogy egy határidős nap esetén mennyi a korrekció, függ attól, hogy előtte mikor mennyi munkanap volt. Tehát ha pl. pünkösd hétfő jön ki, akkor attól függően, hogy húsvét előtt vagy után kérdeztem le, más korrekció kell.
Nem elég egyszer feltölteni, mert az, hogy mi munkanap, folyamatosan változhat.
-
bambano
titán
Következőn agyalok: leveleket írok. A levelekben van egy csomó határidő, 8 nap, 15 nap, stb. Jobb lenne az X nap határidő helyett konkrét dátumot írni. Szabály szerint hétvégén és ünnepnapon csúszik a határidő. Van egy táblám (én mindig postgresql
) :
id: bigserial, datum: date, stb...
Ha egy nap hétfő,...,péntek, ÉS nincs benne a táblában, akkor munkanap.tehát konkrét dátumhoz és nap darabszámhoz kellene a dátum, ami annyi munkanappal később van.
valaki akar egy ilyen sql lekérdezésen agyalni?
előre is kösz. -
bambano
titán
postgresül így néz ki:
with T as (
SELECT date_part('year',Zeit) as Year,
date_part('month',Zeit) as Month,Zeit, zaehlerstand,
Zaehlerstand-coalesce(
lag(Zaehlerstand) over (order by Zeit),
zaehlerstand) as Consumption
FROM Energy)
select year,month,sum(consumption) from T
group by 1,2 order by 1,2;a problémád az lehet, hogy a lag függvény az első sorra NULL értéket ad, ezért a kivonás nem működik. tehát nem nullát, hanem NULL-t. ezt lehet kikerülni a coalesce függvénnyel.
-
bambano
titán
lehet az a baj, hogy a group by és a lag sorrendje nem az, ami neked jó.
ezért javaslom a subquery-t. valahogy így:with alselect as (SELECT Month(zeit) as Month,Zaehlerstand - lag(Zaehlerstand) over (order by zeit) as "Consumption" FROM database.table)select * from alselect group bystb. nem ismerem a mysql-t, a pontos szintaxist az olvasóra bízzuk
-
bambano
titán
ha nekem kellene ezt a problémát megoldani, első nekifutásra biztosan nem sql-lel foglalkoznék, hanem megnézném, hogy van-e erre a Grafana-nak megoldása. Az ilyen grafikonrajzoló cuccok ősének tekinthető mrtg ezt alapból tudta kezelni. emlékeim szerint gauge volt a konfig opció.
-
bambano
titán
a tábla szerkezetét az adatstruktúra normalizálása alakítja ki és nem más.
a másik alapvető dolog, hogy a redundanciából és a szinkronizálásból *MINDIG* baj lesz inkább előbb, mint utóbb.egyébként postgresben fel lehet csatolni másik adatbázist, végszükség esetén ez is jó lehet. a te tábládat a kolléga felcsatolja egy saját adatbázisba és mellérakja külön táblában a saját mezőit.
-
bambano
titán
én még nem láttam olyat, hogy postgres kész applikációval úgy működjön, ahogy te leírtad.
nevezzük nevén a gyereket: gyári multimaster postgres tudtommal nincs.
tehát vagy csináltok valami cuccot, amitől multimaster lesz a postgres, és komolyan hiszek benne, hogy nem fogjátok tudni normális költséggel normális idő alatt megoldani,
vagy megváltoztatjátok az adatszerkezetet úgy, hogy ne kelljen multimastert csinálni, mindig pontosan egy irányba menjenek az adatok.az külön necces, hogy egyes gépen hol van net, hol nincs, ahelyett, hogy ilyenkor másik gépen keresztül küldi az adatot, inkább oldjátok meg, hogy legyen net. mibe se kerülne egy építési területre saját wifit telepíteni...
-
bambano
titán
biztos, hogy ezt akarod? nekem nagyon rossz érzésem van a kérdéseddel kapcsolatban, az ilyen megoldásoknak szinte biztosan nagy kavarodás lesz a vége.
mondjuk jó lenne tudni a probléma részleteit is, hogy pl. mennyi adat keletkezik, mennyi idő alatt kell feldolgozni és van-e olyan más gépen keletkezett adat, amit vissza kell tölteni a gépekbe.szerintem naplózásra a syslog való, és annak van olyan verziója, ami kezeli az általad írt problémákat is. Balabit vagy Balasys vagy hogy hívják őket a héten, fejlesztette, pénzes.
táblák szinkronizálására vannak postgreses cuccok, én nem kezdenék velük
Slony és társai. -
-
#5497
bambano
titán
NeoPampalini
#5494
bambano
titán
válasz
NeoPampalini
#5494
üzenetére
az lehet a gondod, hogy a karakterek tárolási mérete változik.
ezért ha blob mezőben substr-t csinálsz, elvileg előfordulhat, hogy ketté vág egy karaktert, ami két bájton tárolódik. nem tudom, hogy az oracle ezt hogy intézi, php-ben futottam bele ilyenbe.
olyan substr függvényre lenne szükséged, ami tisztában van az utf8-cal.lehet, hogy a blobot először utf8-as text-té kellene konvertálnod, és utána substr-rel vágni a szükségest.
-
-
bambano
titán
"Kérdés, hogy a bíróság elfogadja-e ezt hitelesnek.": nem és nem.
tehát nem kérdés, nem fogadja el.
az elektronikus személyire pakolható elektronikus aláírás kettő évig érvényes, ezért az aláírás csak akkor érvényes, ha a dokumentumon olyan, magas biztonságú időbélyeg is van, amelyik az aláírás érvényességi idejébe beleesik. -
bambano
titán
válasz
sztanozs
#5126
üzenetére
"az indexet növekvő sorrendben hozza létre így az index végén levő (legnagyobb értékek) rögtön rendelkezésre kell álljanak": szemben azzal, ha csökkenő sorrendben hozza létre, mert akkor az index elején áll rendelkezésre a legnagyobb érték.
normálisan az indexet egyféleképpen kell létrehozni, és ha csökkenő a lekérdezés, akkor egyszerűen reverse scan-t csinál. legalábbis a postgres ilyen, hogy más adatbáziskezelők mit csinálnak, nem tudom.
-
bambano
titán
további problémának látom a felesleges joinokat.
mivel az items_categories táblában a category_id egyenlő a categories táblában a category_id-vel, ezért csak abból a célból, hogy szűrni lehessen rá, tök felesleges összejoinolni a kettőt. az items_categories táblában pont ugyanúgy lehet szűrni a category_id-re, mint a categories táblában.pontosan ugyanez igaz az item_id-re.
tehát azt kellene csinálni, hogy az items_categories táblából leválogatod azt, ami kell, berakod egy subselectbe (ha a mysql vagymi tud olyat, nem ismerem), és utána ahhoz joinolod hozzá a végén a két plusz táblát.
ekkor a két plusz tábla joinját már csak a leszűrt termékekre csinálja meg, és sokkal gyorsabb lesz.valami ilyesmi postgresben az elmélet:
with tetelek as (select * from items_categories wherecategory_id not in (1,3,13,7,20) anditem_id not in (117,132,145,209,211)) select * from items,tetelek,categories where
tetelek.item_id = items.item_id and
tetelek.category_id = categories.category_id;a lényeg, hogy a valódi szűrést a tetelek selectjében érdemes megcsinálni.
-
bambano
titán
válasz
kw3v865
#4995
üzenetére
ezt nem lehet megoldani.
példa: legyen három timestampod, az első és a harmadik egymástól 1 perc 40 másodperc távolságra. A középső meg félúton. Akkor a középső melyikhez tartozik?egyébként timestampokat ki lehet vonni egymásból, timestamp lesz az eredmény, amit lehet konvertálni egész számmá.
-
bambano
titán
jó lett volna, ha leírod, hogy milyen adatbáziskezelőről van szó.
a későbbi hsz-eid alapján ha találgatnom kellene, azt írnám, hogy mysql.
miért nem postgresql?igen, jól érted. a jól normalizált adatszerkezet lényege, hogy később sem kell belenyúlni. ha most rakás táblád van és azt később bővíteni kell, akkor a lekérdezésekbe is bele kell nyúlni, meg mindenbe.
a lényeg, hogy el kell választani a logikai sémát a tárolási sémától. a logikai séma azt mutatja meg, hogy hogyan kell kinézzen az adatbázis, miután normalizáltad. a tárolási séma meg azt, hogy indokolt esetben miben tér el a logikai sémától.
amit emlegettek mások is, ha nagy a tábla, akkor lehet particionálni a táblát. ráadásul ha külön tablespace-be teszed a partíciókat, akkor a diszk elérés is gyorsulni fog (régen a mysql tudott raid0-t, de kivették belőle...)
mondjuk az is relatív, hogy kinek mi a nagy adatbázis. a postgesql párszázmillió rekorddal még szépen elgurul. utána kell elkezdeni tákolni a tárolórendszert hozzá.
-
#4896
bambano
titán
Apollo17hu
#4895
bambano
titán
válasz
Apollo17hu
#4895
üzenetére
nagy erőkkel lassítod a lekérdezést?
miért nem group by 2? -
bambano
titán
válasz
#29736192
#4830
üzenetére
mindig jó ötlet az adatbáziskezelőn belül tartani a melót.
tehát ha meg tudod úgy oldani a programot, hogy ne kelljen kihúzgálni az adatot az sql szerverből, akkor az jobb.ezzel szemben van az, hogy jelen esetben is elszállhat a memóriaigény.
legegyszerűbb kipróbálni és megmérni a lehetséges verziókat.
nálad probléma lehet, hogy ebben a megoldásban a regexp rámegy azokra a sorokra is, amiket egy korábbi regexp már kizárt, ami elég nagy pazarlás. tehát ha külső nyelvből csinálnád a keresést, akkor lehet, hogy egyszerűbb lenne úgy, hogy csinálsz egy temporális táblát, abba belerakod az összes adat azonosítóját, amit az első regexppel szűrtél és még kell, majd utána a többivel sorban kiszórod belőle azt, ami nem kell. ha a regexpeket gyakoriság szerinti csökkenő sorrendben teszteled, akkor az hatékonyabb lesz.
-
-
bambano
titán
-
-
bambano
titán
úgy kezdted a megoldásodat, hogy csináljon másolatot a tábláról.
ez már önmagában zűrök okozására ad lehetőséget.
ha például jávába beolvasod az adatokat, feltéve, hogy beférnek, akkor is ott lesz a probléma, hogy a riport futtatása közben vásárolnak, és akkor szétszalad a valós raktárkészlet adata meg a temp tábla adata."minden egyes lépés kiértékelésénél a DBnek egyesével újra kell számolnia az eddigi lépések eredményét": ez tény, de feladattól, környezettől függ, hogy ez hátrány vagy előny.
nekem az a véleményem, hogy hagyni kell az adatbáziskezelőt dolgozni.
az, hogy a bi ócska, az másvalaki problémája
vegyenek bele több ramot. -
bambano
titán
válasz
mr.nagy
#4729
üzenetére
én ezt úgy csinálnám, (mssql-hez nem értek), hogy csinálnék egy eredménytáblát, amibe beleírom, hogy honnan hova, ahogy te is felírtad.
majd csinálnék egy nézettáblát, ahol összeadnám a nyitó készletet és a mozgásokat, és az lenne az eredmény.
az eredménytábla feltöltését pedig a nézettábla alapján csinálnám meg.
majd csinálnék egy ciklust, ahol kiválasztanék egy honnan meg egy hová üzletet (például az alapján, hogy mekkora a hiány vagy mennyire nagy a készlet) és az alapján pakolnék a mozgás táblába.a javaslatom az, hogy minden olyan megoldástól visítva menekülj, ami redundanciát okoz.
-
-
bambano
titán
szerintem ez a megoldás nem a kérdésre ad választ, mert ez csak azt mondja meg, ha két egymásutáni rekordnál rossz a dátum sorrendje, azt nem, hogy két tetszőleges rekordnál is az.
tehát ha van egy id=300, datum='2019-07-30' rekordod, azt a te megoldásod nem találja meg, az enyém igen. a kérdés, hogy a kérdező mit akart kérdezni
-
#4665
bambano
titán
RoyalFlush
#4664
bambano
titán
válasz
RoyalFlush
#4664
üzenetére
valahogy így:
select t1.*,t2.* from datumok t1, datumok t2 where t1.id>t2.id and t1.datum<t2.datumfejből írtam, nem biztos, hogy szintaktikailag helyes.
-
) és akkor lefekszik az egész....
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Filmvilág
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Luck Dragon: Asszociációs játék. :)
- Autós topik
- Kerékpárosok, bringások ide!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Az Euronics is elkezd használt mobilokkal foglalkozni
- Interactive Brokers társalgó
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- Samsung Galaxy S23PLUS 256GB Kártyafüggetlen 1Év Garanciával
- AKCIÓ! Dell Optiplex 5050 SFF asztali számítógép - i5 7500 8GB DDR4 256GB SSD HD630 Win10
- Külföldi csomagszállítás Packeta csomagpontokon keresztül!
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest