- Milyen processzort vegyek?
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- 3D nyomtatás
- Milyen billentyűzetet vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- OLED TV topic
- Gaming notebook topik
- Vezetékes FÜLhallgatók
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
Hirdetés
-
Mozgóképen a Razr 50 Ultra még nagyobb kijelzője
ma A hivatalos kedvcsináló megnyerő, csak nem hivatalos forrásból érkezett.
-
Ellopták a Tesla akkumulátor-titkait
it Beperelte egy korábbi beszállítóját a Tesla, és azzal vádolja, hogy üzleti titkokat lopott a Tesla akkumulátorgyártási technológiájával kapcsolatban.
-
Továbbra is roppant népszerű a Resident Evil 2 Remake
gp Jelenleg több mint 13,9 millió példányt adtak el a játékból és még mindig sokan érdeklődnek a felújítás iránt.
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz dellfanboy #1185 üzenetére
Igazából szerintem így lenne értelme:
...
WHERE UPPER( stuff_name ) LIKE UPPER( '%lajos%' )...abban az esetben, ha az adatbázis case sensitive.
Pl. MySQL-nél alapból tök mindegy, hogy "lajos", "LAJOS" vagy "LaJoS" a tárolt név, simán az UPPER nélkül is kiadja mindegyik találatot, szóval ez case insensitive módon megtalálja az összeset - de collationnel arra is van mód, hogy ne így legyen: [link].Case sensitive esetben viszont mindkettőt jó, ha nagybetűssé teszed, és úgy veted össze, mert ellenkező esetben nem mindegy, hogy a fent felsorolt példák közül hogyan keresel rá.
Tehát ha nem mindkettőnek a nagybetűssé (vagy épp kisbetűssé) tett változatát veted össze, akkor lehet, hogy egyes találatokat kizársz az eredményekből, mert mondjuk valaki elgépelte a Lajost, és LajOst írt helyette (lásd nagy O).
A nagybetűssé tett "lajos"-ból "LAJOS" lesz, a nagybetűssé tett "LajOs"-ból is "LAJOS" lesz, tehát így már a két karaktersorozat egyezni fog ebben az 5 karakterben.
A Te fenti keresésed lehetővé teszi azt is, hogy a "LajOska" nevet is megtalálja.Remélem így valamennyire érthető.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #1187 üzenetére
Pontos egyezés vizsgálatához át lehet alakítani így is:
SELECT * FROM `test_names`
WHERE
BINARY(stuff_name) LIKE "%lajos%"Így csak azt találja meg, ahol "lajos" vagy "lajoska" van, a "Lajos" vagy "LaJos", stb. neveket már nem.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Na, a kérdés maga annyira megzavart, hogy már én is félrebeszéltem, meg pontatlanul is írtam, bocsi. A kérdező azt írta, hogy "A dátum 2003.11.26. 10:28:14 ilyen formátumban van.", én ebből úgy értelmeztem, hogy valamilyen oknál fogva string típusként van TÁROLVA az adatbázisban (most szándékosan írtam tárolást!! Mindegy, hogy varchar vagy egyéb ilyen jellegű típusról van szó, és NEM a dátumformátumok valamelyikéről, aminek nyilván megvan a maga tárolási módja, de attól még valamelyik tényleges dátumformátumról van szó), ezért kénytelen vagdosni, stb., de akkor valószínű félreértettem az eredeti felvetést.
Utána már azt is félreértettem, amit Te írtál, pedig így másodszor elolvasva elég világos, hogy itt csak dátum-megjelenítési formátumot változtatsz, attól még nem tárolod másik formában.
Akkor most megpróbálom értelmesen megfogalmazni: arra gondoltam, hogy még a megjelenítési formátumot sem biztos, hogy szerencsés, ha az ember változtatja, mert ha mondjuk egy alkalmazást megír (hogy most az asztali vagy webes, tök mindegy), ami az adatbázistól bizonyos formátumban (megjelenítési formátumban) vár adatokat, és tök más formában kapja meg, mint egy másik szerveren, akkor abból adott esetben probléma lehet - mondjuk a probléma kimerül annyiban, hogy át kell állítani a formátumot úgy, ahogy mutattad, de nem biztos, hogy azonnal leesik, mi is a gond.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz SektorFlop #1220 üzenetére
Más, mert a többiek az eredeti kérdést már megoldották: miért nem használsz prepared statementeket? Ez a query-konkatenálás nagyon csúnya és kerülendő megoldás.
(#1238) Fecogame :
Mit értesz azalatt, hogy "egybeolvasztani"? Magyarul egy adatbázisba rakni? Mi vele a problémád?
Amúgy azonos tárhely alatt akarsz két fórummotort használni, vagy két különbözőn?
Ha az első, akkor annak mi értelme? Ha a második változat, akkor viszont meg kell oldani a külső hozzáférést is az adatbázishoz.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz wolandino #1255 üzenetére
10 évvel ezelőtt sem értem, minek írtak ékezetet a táblanevekbe. (Mondjuk semmilyen kódba nem szabad ékezetet tenni, legfeljebb kommentbe.)
Nem tudod átszabni a jelenlegi adatbázis-struktúrát? Mindenhol lecserélni az ékezetes táblaneveket is (gondolom ehhez tartozik valami alkalmazás, ott is átírni), plusz Access helyett valami értelmesebb adatbázist alkalmazni. Ehhez nem is kell átírni a teljes alkalmazást, ami nyilván nagyon időigényes, csak legalább ezeket kellene lecserélni, ez akár max. pár óra alatt is kivitelezhető lenne.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz martonx #1260 üzenetére
Amennyire én értettem, rákényszerítik a Linux-környezetet, amiben használnia kell a meglévő, ósdi fosadék rendszert, ami alapvetően MS-alapú, és jelenleg egyszerűbb hozzátákolni némi plusz PHP-kódot, hogy elérje/módosítsa az adatokat, mint az egészet átültetni egy totál új rendszerbe (új adatbázist használva, új alkalmazást fejlesztve), mivel az új rendszer fejlesztése, a régi lelövése épp túl nagy időbeli és anyagi befektetést igényelne. Nyilván ő sem szívesen választotta ezt a gányolást, de ha ez van, hát akkor ez van... ne oltsd le szegényt azért, mert időszűkében kényszermegoldást választ, valószínű, hogy rövidebb alatt sikerült működő tákolmány megoldást találnia, mint amennyi idő alatt egy új rendszert kialakított volna, tulajdonképpen nem ő a hibás azért, hogy kapott egy szar feladatot, egy gány adatbázist és egy szar alkalmazást. Feltételezem és remélem, hogy majd áttérnek normális rendszerre.
[ Szerkesztve ]
Sk8erPeter
-
-
Sk8erPeter
nagyúr
válasz sanzi89 #1280 üzenetére
Nem az a baj, hogy a "log" egy foglalt név? Ilyen problémával már találkoztam MySQL-nél, és ott az a megoldás, hogy köréteszed a visszafelé dőlő aposztrófot, aminek most nem jut eszembe a neve
Tehát
log
helyett
`log`De mindez Access-ben nem rémlik, megy-e, szerencsére nem sok dolgom volt Access-szel.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sztanozs #1291 üzenetére
Ja, hogy így. Igen, mondjuk adatbázisonként eltérhet a formátum, MySQL-ben ilyen: [link]
"MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'."MSSQL-ben: [link]
"Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds"Egyébként konkrétan azért kérdeztem vissza, mert feltételezem, a TÁROLÁS módja a háttérben (tehát magának az adatbázis-kezelőnek a szintjén) viszont általánosan van megoldva, tehát ez alapján magából a tárolt értékből ki lehet nyerni a megfelelő dátumot, legfeljebb lekérdezéskor előfordulhat, hogy valaki nem megfelelő formátumban adja meg a datetime-ot, és akkor nem azt az eredményt kapja, amit elvárt; vagy épp feltöltéskor más formátumban adja meg, mint ami az elvárt, és "rossz" datetime tárolódik, nem?
Mondjuk egy UNIX timestamp legalább valszeg mindenhol ugyanolyan.
"Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás"
Itt viszont nem értem, miért emeled ki a konkatenálást, mert elvileg akkor épp azért, amiről beszélünk, tök mindegy, hogy most konkatenálva adtál át rossz formátumot, vagy prepared statementként.Gondolom erre a képre gondoltál: [link].
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sztanozs #1293 üzenetére
Attól függ, milyen prepared statementről beszélsz, mert most már nem egyértelmű számomra.
=========================
(#1294) rum-cajsz : jaja, ArchElf készítette, mert a t×künk tele volt a PHP topicban a sok konkatenált fosadék query-vel. Elég találó.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sztanozs #1299 üzenetére
Még mindig nem értem, hogy ez önmagában miért oldaná meg azt, ha a fejlesztő vagy a user rossz inputot akarna megadni a datetime mezőhöz. A kiindulópont ez volt, erre állítottad, hogy ez egy megoldás lehet, de még mindig nem mondtad el, hogyan kínál ez áthidaló megoldást nyelvektől függetlenül.
===
(#1298) martonx : igen, de most nem ez a lényeg, hanem hogy ez hogyan oldja meg a rossz formátumok problémáját (ha már ez volt az állítás), amiről korábban szó volt.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz rum-cajsz #1302 üzenetére
Idézem, amit itt írt:
"egy 10/11/12-ről megmondani, hogy mi volt az eredeti dátum 33%-os eséllyel lehet - és az adatbáziskezelő is ilyen eséllyel vesz fel jó értéket."
Ez egy jogos szempont, erre hogy alkalmazol dátumkonverziós függvényeket úgy, hogy biztosan a jó eredményt kapd?
Még akkor sem egyértelmű, ha legalább az évszám négy számjegyű, mert így is felcserélődhet a nap-hónap.====
(#1301) sztanozs : ez végül is igaz.
Mondjuk a UNIX timestamp (másodpercek) legalább tuti nem téved, aztán abból akármilyen formátumra is átalakíthatod.
A felhasználói inputnál meg normális esetben a normális fejlesztő úgyis megoldja, hogy a dátum szigorúbb feltételekhez legyen kötve, akár szétbontva a dátumot külön-külön mezőkre (év, hónap, nap, stb.), akár egy JavaScript-alapú datepickerrel egyszerűbbé téve a választást.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz rum-cajsz #1304 üzenetére
Na várj, szerintem elbeszélünk egymás mellett.
Senki nem is mondta eddig, hogy a prepared statement ne lenne jó, sőt, eddig mindenki amellett érvelt. Amit sztanozs felhozott, az az, hogy adatbázisonként eltérhet a datetime formátuma (erre én is linkeltem a MySQL-es, meg az MSSQL-es példát, hogy máshogy néz ki), ez már eleve problémát okozhat, tehát hiába adsz át stringként prepared statementtel valamit, ha a formátum akkor is rossz, mert mondjuk más formátumra van konfigurálva az adatbázisszerver, vagy mittudomén.
De már kezdek én is belezavarodni."Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda."
Agreed.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sanzi89 #1308 üzenetére
Szerencsére nem sok dolgom van Access-szel.
De gyorsan rákeresve ezzel pl. lehet böngészni Access adatbázist is: RazorSQL
Lehet, hogy elbeszélünk egymás mellett, de amit írtál, azt úgy értelmezhető, hogy összesen 2 egyező sor van, és az egyiket törölni kellene. De javíts ki, ha arra gondolsz, hogy MINDEN sorból dupla van......
Ha viszont csak egy, akkor igazából nem vágom, hogy most mi is a probléma, egy rendes grafikus alapú adatbázis-kezelőben csak az adott sornál rámész, hogy delete, és meg is vagy. Vagy beadod query-ként, most csak legegyszerűbb példával élve:
DELETE FROM akármitábla WHERE id = 3
[link]Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sanzi89 #1315 üzenetére
Nem tudom, mi a frászt vársz, amikor az elején nekünk kell helyetted kitalálni az infókat, belőled meg harapófogóval kell kihúzni...
Ha szarul teszed fel a kérdést, talán ne lepődj meg, hogy nem kapsz egyből konkrét választ. És ne forgasd a szemeidet, ha már te kérsz segítséget...Sk8erPeter
-
Sk8erPeter
nagyúr
válasz sanzi89 #1318 üzenetére
Abban igazad van, hogy írtad, hogy nincs kulcs, ez őszintén szólva kissé számomra elsikkadt a hsz.-ek után. DE ilyen alapon - ha már ilyen jól belejöttünk az egymásba való belekötésbe - attól még tartozhat valami olyan mező is a táblához, ami alapján egyértelműen lehet azonosítani az adott sort (még ha nem is ténylegesen KULCS az adatbázis szintjén!!), de erről sem írtál SEMMIT, tehát fogalmunk nem lehetett az adatbázis-szerkezetedről sem.
Delphi? Mutasd már meg, itt hol írtál ilyenről egyáltalán: [link]. És ha Delphi, akkor mi van? Ez a rész a lényeg szempontjából miért érdekes? Attól még miért ne lehetne akár grafikus alapú adatbázis-kezelőből módosítani az adatbázist? Mi köze a kettőnek egymáshoz?
A sok-sok (!!) duplikációval kapcsolatban meg hadd idézzelek:
"Van benne 2 sor, ami totálisan megegyezik, minden mező értéke ugyan az."
Amit itt írsz, azt jelenti, összesen 2 sorral van problémád. Ebből tehát rohadtul nem derül ki az, amit a későbbiekben írtál le, hogy SOK duplikáció van, ergo NEM csak két sor."Van egy táblám, benne adatok."
Semmi információ arról, hogy ez Access lenne, és milyen adatokról van szó (értsd: adatbázis-struktúra, esetleg példa).Idióta visszakérdezgetések és a mostani, tök felesleges veszekedés és e-pénisz-villogtatás elkerülése érdekében pl. feltehetted volna a kérdést úgy (csak egy példa), hogy "van egy Access-táblám, semmilyen mező nem azonosítja egyértelműen a sorokat (nincs azonosítójuk), és elég sok sor duplikálva van. Milyen módon tudnám megszüntetni a duplikációt?
Struktúra:
ABCDE
Egy konkrét példa egy sorra (ilyenből van kettő):
XYZ"======
(#1319) -Zeratul- : ja, nyilván a kérdés tökéletes volt. Azért olvasd el a fentit, hogy hogyan lehetett volna elkerülni, hogy most itt ilyen óvodás hőzöngés alakuljon ki.
Sk8erPeter
-
Sk8erPeter
nagyúr
modder sok mindent leírt előttem, ami a megvalósítást illeti, tehát azzal a résszel egyetértek. Viszont én még annyit tennék hozzá, hogy bennem a hsz.-ed láttán egyből az a kérdés merült fel, hogy vajon miért feltételezed, hogy a hirdető egy külön állatfaj. A hirdető is egy regisztrált felhasználó, tehát egy user, akinek a helye a user táblában van. Tehát teljesen felesleges a "hirdető neve, hirdető kora, hirdető egyéb adatai", stb. adatokat külön táblában tartani. Ez a felhasználóhoz tartozó adat (user tábla, vagy esetleg egyéb adatok miatt ehhez kapcsolt tábla, de ez opcionális). Az már másik kérdés, hogy ez a felhasználó egyáltalán hirdethet-e, ad-e fel hirdetést, és ha igen, az adott hirdetésekhez milyen adatok tartoznak.
Itt most a hirdetés hozzákapcsolása szempontjából tehát mellékes, hogy szerepkör alapján hirdethet-e csupán a felhasználó, vagy bármilyen bejelentkezett felhasználó feladhat hirdetést. Nyilván egy expressz.hu-hoz hasonló oldalon az a fő profil, hogy bárki feladhasson hirdetést (mondjuk adott összeg befizetése után), tehát ott nem kell külön hirdető szerepkör (hacsak nem a fizetés után kapja meg a felhasználó a "hirdető" szerepkört, ami akár le is járhat, de még ezt a kérdéskört is lehetne boncolgatni).Lényeg tehát: a hirdető is egy felhasználó. A hirdetés pedig külön adat, ami - ahogy előttem elmondták - egyértelműen egy felhasználóhoz tartozik (elég ritka az az eset, hogy több embert akarsz megjelölni hirdetés feladójaként...), tehát itt nem kell külön kapcsolótábla a hirdetés-user kapcsolathoz.
Sk8erPeter
-
Sk8erPeter
nagyúr
Akkor ezt folytatva: mindenki érti már szerintem, mit szeretnél, úgyhogy még egy ilyen csodás példa nem kell a magyarázat tisztázásához . Előbb linkelt cucc utsó hsz.-ében leírtam, hogy OK, minden hirdető júzer, de nem minden júzer hirdető.
Tehát akkor rövidre zárva a dolgot: nem kell az a kapcsolótábla. A hirdető egyéb adataiba egyszerűen bepakolod a user id-t.Persze lehet ezt tovább bonyolítani, ha még tovább lenne bontva, hogy bizonyos hirdetőknek extra paramétereik lehetnek, és akkor megint előkerül a probléma, hogy NULL értékűek bizonyos paraméterek azoknál a hirdetőknél, amelyeknél nincsenek meg azok az extra paraméterek.
Akkor már egy táblába kéne pakolni a user id-t, paraméter id-t, paraméterhez tartozó egyik lehetséges value id-t, és így tovább... de gondolom nálad egyezne az összes hirdető plusz adata.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Dave-11 #1361 üzenetére
"Állítólag nagyon hasznos"
Ki szerint? És milyen célra hasznos?"ami ezt a fajta használatát mutatja be"
Melyik fajta használatát?Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják. Ezerszer hasznosabb, ha a MySQL-re fekszel rá (ha már amúgy is van valami előismereted), vagy MS SQL Serverre, Oracle-re, stb... na, ezek hasznosak.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz martonx #1364 üzenetére
És ez szerinted jó?
Amúgy az Exceles+TXT-s+rendes adatbázisos összekattintgatós móka valóban egyszerűnek tűnik, bár ha normálisan egységesítve vannak a dolgok, akkor elvileg nem lenne szükség TXT-re és Excelre, de nem akarok naiv lenni, tudom, hogy ez soha nincs így. Tehát az a funkciója hasznos lehet.Amúgy sorolhatnál pár ilyen pénzintézetet (!), ahol az Access a fő alap, tényleg érdekelne.
Sk8erPeter
-
Sk8erPeter
nagyúr
Azt sem írtad, milyen SQL konkrétan. Ha már vágod az SQL-t, elvileg mindegynek kéne lennie, melyiket használod, gyorsan át tudsz állni rá.
Nekem pl. MySQL-hez a dbForge Studio for MySQL jött be eddig legjobban, de még nyilván van hatszáz másik fasza program.
Microsoft SQL Serverhez meg persze Microsoft SQL Server Management Studio.Sk8erPeter
-
Sk8erPeter
nagyúr
"-labels ( ez egy olyan varchar lenne, ahol a label_id-k vanak tárolva, például ilyen formátumban: |1|34|45|54| ) - magyarul, minden egyes label_id | | között lenne."
Ha hatékony megoldást keresel, egyből le kéne, hogy essen, hogy ez aztán garantáltan nem lesz az.
Amúgy sem értem, minek kéne ilyen pipe-pal elválasztva tárolnod, amikor létrehozol neki egy külön táblát... A product id-val kéne összekapcsolnod, aztán kész.
Csak gondolj bele, hogy hogyan tudnál ezek között hatékonyan keresni, ha stringben egybe van b@szva... hatékonyan sehogy.Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
"suli-ban" sulitiltás?
A tárolt eljárás pedig sokszor jó kis segítség tud lenni, például ASP.NET-ben. Amúgy a tárolt eljárás arra is jó, hogy nem kell a query-vel elrondítanod az alkalmazásod kódját, hanem az adatbázisban tartod azt, aminek épp ott a helye, vagy amit úgy érzel, nyugodtan rábízhatsz az adatbázisra, és azt terheled a feladat megoldásával, stb. Meg így adhatsz neki egy jó beszédes nevet, aztán meghívhatod az alkalmazásod kódjából a megfelelő paraméterek átadásával. Csomó mindent el lehet intézni benne, ami csúnya lenne alkalmazásból, vagy épp nem akarsz ORM-et igénybe venni rá, satöbbi.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Inv1sus #1497 üzenetére
"A kategóriákat '|' jellel elválasztva rakom be az adatbázisba"
Ez az, amit kerülj el, válaszd szét rendesen. Sok sort fog eredményezni, de az nem baj. Annyi sor lesz, ahány taget/terméket/akármit akarsz hozzákapcsolni az adott entitáshoz.Leegyszerűsítve:
termékek tábla
-----------------------
id ; termék neve; kategóriák
123 ; én termékem ; kategória1|kategória765HELYETT
termékek tábla
-----------------------
id ; termék neve
123; én termékemkategóriák tábla
-----------------------
id; kategória neve
1; kategória1
765; kategória765termékek-kategóriák összekapcsoló tábla
-------------------------------
id; termék_id; kategória_id
1; 123; 1
2; 123; 765Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #1504 üzenetére
De ilyen tagelés-kategorizálás esetében miért lenne már jó a pipe-karakterrel elválasztott módszer? Indokot még nem írtál, szerintem jogos volt, hogy elég csúfnak találták a megoldást a többiek, meg én is.
Nehézkes és lassú lehet a keresése, nehezebb szűrni, eleve ez a LIKE-os megoldás elég hányadék. Nem is lehet normálisan végigiterálni a kapcsolt elemeken. Módosítás/törlés is problémás, és még elég sok más érvet is fel lehetne sorolni ellene.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Új hozzászólás Aktív témák
- Vodafone mobilszolgáltatások
- Battlefield 2042
- Escape from Tarkov
- A fociról könnyedén, egy baráti társaságban
- gban: Ingyen kellene, de tegnapra
- Milyen processzort vegyek?
- Politika
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- Megérkezett a Google Pixel 7 és 7 Pro
- EAFC 24
- További aktív témák...
- MacBook Air M1 256GB SSD 8GB RAM 2025.05-ig Garanciális
- Playstation 5 ( lemezes) + 2 kontroller + töltő
- Custom YMDK 60% + MF17 halkított, átvilágítós magyar bill. + numpad, Outemu Silent Peach v2 switchek
- Asus ROG Strix GTX1060 6GB OC
- CHAMP DM7305 professzionális IP dóm kamera 5MP, vandálbiztos, motorzoom, új állapotban