- Xbox Series X|S
- World of Tanks - MMO
- Dragon's Dogma 2
- WoW avagy World of Warcraft -=MMORPG=-
- Limitált ideig ingyen kipróbálható az Assassin's Creed: Mirage
- Helldivers 2 (PC, PS5)
- Call of Duty: Modern Warfare III (2023)
- EAFC 24
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Fallout 4
Új hozzászólás Aktív témák
-
#68216320
törölt tag
válasz fordfairlane #2652 üzenetére
MySQL Community Server van feltéve. Ebben nincs Workbench. Tegyem fel azt is?
-
fordfairlane
veterán
válasz #68216320 #2653 üzenetére
Én is communityt telepítettem fel, 5.6.21-et. Valami developer install opciót választva a mysql workbenchet és a mysql notifiert is felrakta.
Egyébként a belinkelt leírásban ott van, hogy mit kell beírni a my.cnf-be, úgyhogy megoldható workbench telepítés nélkül is.
[ Szerkesztve ]
x gon' give it to ya
-
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.Én kérek elnézést!
-
Dj Sügi
őstag
Lenne egy egyszerűbb kérdésem hozzátok!
Nem sikerül rájönnöm egy feladat megoldására: Van három oszlopom tele számokkal, ezeket összegezni kell csoportosítva(4db csoportba) de csak a 45-nél nagyobb értékeknek kellene megjelennie!A végét nem tudom megoldani csak, gondolom "having"-el kellene, de a 3 összegzett értékre nem tudom alkalmazni!???
Köszi!
🚗 FORD - First On Race Day 🚗
-
#68216320
törölt tag
válasz martonx #2660 üzenetére
Webtárhelyeken phpmyadmin-t adnak felületnek. Ezért használom azt és maradnék is annál.
Más:
Még soha nem csináltam feltételes (IF) SQL parancsot. Ebben szeretném a segítségeteket kérni egy egyszerű példával.
Adva van egy 'users' tábla többek között email(vchar255), ip(vchar15), proba(int) mezőkkel.
mondjuk a user (email alapján egyedi) egy ip-ről max. 3x próbálhat belépni.
Ha ip-t vált akkor újabb 3 lehetősége lenne, tehát a 'proba' mező értékét 0-ra állítanám.Egy olyasmi kérést csinálnék, hogy:
ha a user táblában az email-el egyező sorban az ip mező értéke nem egyezik az új ip-vel, akkor frissítse ebben a sorban a proba mező értékét 0-ra
Ez hogyan nézne ki helyes szintakszissal?
-
Sk8erPeter
nagyúr
válasz #68216320 #2665 üzenetére
Nem biztos, hogy ezt egyetlen query-vel kell elintézned, lehetne ilyenekre tárolt eljárást is írni. Persze tervezési kérdés, hogy ezt biztos az adatbázisszervernek kell-e intéznie, vagy az alkalmazás(szerver) intézze.
Viszont ez a jelszóbeírásnál legfeljebb 3 próbálkozást megengedő szokás egy időben nagyon elterjedtté vált, valószínűleg azért, mert az emberekben van egy ilyen hülyeség, hogy a 3 az egy olyan szép szám, meg három a magyar igazság, meg hasonló f@szságok, de ez egy ultrabaromság szerintem. Háromszor simán elkúrhatja a jelszót olyan felhasználó is, aki egyébként a felhasználói azonosító "tulajdonosa". Először mondjuk begépel egy olyan jelszót, amit másik oldalon használ, aztán rájön, hogy hoppá, ja, ez nem is az, ami ide kell (1/3). Vagy még az is lehet, hogy megpróbálja még egyszer, mert még nem ugrik be neki, hogy ezt a jelszót nem ezen az oldalon használja, hanem azt hiszi, hogy csak elgépelte. Utóbbi esetben máris 2 próbálkozásnál járunk (2/3). Aztán mondjuk begépelné a jó jelszót, de véletlenül nagybetű helyett kisbetűt ír (tehát megint elgépelte, 3/3). A 3 próbálkozást máris elértük, te meg kitiltod a francba, a felhasználó meg anyázhat, úgysem hallod meg.
Simán lehet, hogy nincs is épp lehetősége IP-címet váltani (mivel mondjuk fix IP-címet kap).
Nyilván a próbálkozások számát korlátozni kell, mivel így az automatizált kísérletek számát is korlátozni tudjuk, de akkor már jóval értelmesebb megkövetelni egy komolyabb kritériumoknak megfelelő (pl. kellően hosszú, stb.) jelszót, és egy pár próbálkozás után alternatív megoldásokhoz folyamodni (és csak még több próbálkozás után kitiltani átmenetileg).
Ha megnézed, pl. a Google-fiókhoz való bejelentkezésnél sem tilt ki 3 próba után: egy pár elrontott próbálkozás után CAPTCHA megfejtését is követeli, ezzel máris szűri az automatizált kísérleteket (legalábbis azok egy részét biztosan).
Gondoltam megemlítem, hogy fontold meg ezt a 3-as számot azért, túl kevés.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #2669 üzenetére
Mondjuk az nem túl jó, mivel akkor könnyű "segíteni" a dolgon egy sima session cookie-törléssel, és máris olyan, mintha egyszer se próbálkozott volna.
Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #2670 üzenetére
Az biztos, hogy belépési próbálkozásokat én nem user táblában tárolnám el, elvégre a user azonosítót is el lehet gépelni.
x gon' give it to ya
-
jaszy91
aktív tag
Sziasztok!
Van egy furcsa problémám.
Adott két blade szerver, amin SQL Server 2012 fut cluster-ben. Mivel nincs fizikailag közös meghajtójuk, ezért egy virtuális gépen van megosztva egy meghajtó és oda ír.
Ha TC-ből vagy intézőből lépek rá nincs gond, írni, olvasni törölni tudok. Full Control-on van mindenki.
New Database-t létre tudok hozni, és törölni is.
De ha Attach, vagy Restore-nál bejön a felület. Kiválasztom a device-t, és mikor ki keresném egyből hibával elszáll, fel sem dobja a hogy honnan keressem ki. Hiba üzenetben az áll, hogy nem találja, nem elérhető, vagy nincs jogom hozzá.Full Control mindenkinek, látszik a meghajtó és írni is tudok rá.
Valami ötlet?
Üdv,
PéterAMD Ryzen 9 5900x - MSI RTX 4070 Super Gaming X Slim - Kingston Fury 2*16GB 3600Mhz - Seasonix GX750 - Samsung 970 EVO Plus 256GB/1TB - Asus GT501 - Dell S2522HG // iPhone 15 128GB Blue
-
dellfanboy
senior tag
lehet már fáradt vagyok és a megoldás egyszerű de nem jövök rá
adott 1 tábla ahol van 1dátum oszlop 1 ugyfelid oszlop és 1 autóid oszlop.
azon ügyfeleket keresem aki1 hónapban 1 autót és csakis 1et használt, 1 üf használhat több autót is ekkor több autoid lesz a neve melletha leszűrök arra hogy pl március, és autó id pl XX az azért nem jómegoldás mert az az ügyfélid is benne van aki xx autóid előtt után más autót használt. tehát nekem csak azon ügyfél id kell akinek csak 1 autó id-ja van az adott periodusba
remélem érthető voltam de ha ezt írom
select * from tábla
where period március
and autoid =xxakkor azok vannak benne akiknek az adott hónapba volt egyszer egy xx id nem pedig a teljes hónapba az az 1 xx tip
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
Ispy
veterán
válasz dellfanboy #2673 üzenetére
select year(period), month(period), ügyfél_id
from tábla
group by year(period), month(period), ügyfél_id
having count(*)=1"Debugging is like being the detective in a crime movie where you're also the murderer."
-
#68216320
törölt tag
válasz Sk8erPeter #2667 üzenetére
Nos, csináltam egy ilyesmit csak próbából az egyik már nem működő, régi weboldalam belépéséhez. Több lépésből csináltam végül, nem egy query lett. IP alapján blokkol x próba után és egy e-mail címre kiküldött linkben lehet feloldani a blokkolást és újra próbálkozni.
-
dellfanboy
senior tag
köszi
hogy nézne ki, ha van totálba 10 autó id-m és ebből 5-re szeretnék szűrni? having count5 és kész?tehát ügyfél id-k adott periódba ahol az autóid meghatározott 5. (összesen 10 autó id van a táblábA)
simán autoID in (megfelelő 5) és a végén havingxount5
csak azért mert így módosítottam amit írtál és már reggel 8 óta fut.eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
Panthera
őstag
Sziasztok!
Egy Mysql adatbázis napi mentését hogyan lehet megoldani a legegyszerűbben (úgy, hogy ne kelljen az Administrator alkalmazás hozzá)?
-
-
Phvhun
őstag
Van egy Sql-es kérdésem a weblapkészítés topikban, nem akarom duplikálni a tartalmat, szóval csak linkelek, rá tudnátok nézni? [link]
-
Memphis
tag
Sziasztok,
lehet, hogy már volt javaslat a problémámra, de ennyi hozzászólást nem tudok visszaolvasni.
A helyzet a következő. El akarok indítani egy vállalkozást ami értékesítéssel és tanácsadással foglalkozik. Egy olyan programot szeretnék amibe be tudom vinni az értékesítendő terméket, illetve a vásárlók igényeit. Meg persze a vásárlókat.
pl. mondjuk van egy ingatlan iroda és beviszem az eladó lakásokat meg a vevőket. és akkor ezekhez tudnék megjegyzéseket fűzni, esetleg párosítást lefuttatni vevő és eladó között.
ez most egy példa. nem kell, hogy ingatlanos programokat ajánljatok (ha vannak), igazából az lenne a lényeg, hogy a program tudja kezelni az "A" halmazt meg a "B" halmazt, és ezekbe a halmazokba be tudjak vinni értékeket.
valaki tud javasolni valamit? már ha egyáltalán érthető volt a kérdés???
köszi és üdv
Ha ma nulla CELSIUS fok van és holnap kétszer olyan hideg várható, hány CELSIUS fok lesz holnap? :D (bezártam a kiskaput)
-
Ispy
veterán
válasz Memphis #2681 üzenetére
Nem értem mi a kérdés?
tudja kezelni az "A" halmazt meg a "B" halmazt, és ezekbe a halmazokba be tudjak vinni értékeket
Igen, nagyjából ezt tudják az adatbázis kezelők, szóval tk. bármelyiket választhatod.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Memphis
tag
hogy ismersz-e ilyen adatbázis kezelő programot. ami a fenti igényeknek többé kevésbé megfelel.
a fórumban rákerestem arra, hogy adatbázis kezelés, és egy srác egy hasonló kérdést tett fel, mire ezt a topicot javasolták neki.
[ Szerkesztve ]
Ha ma nulla CELSIUS fok van és holnap kétszer olyan hideg várható, hány CELSIUS fok lesz holnap? :D (bezártam a kiskaput)
-
válasz Memphis #2683 üzenetére
neked nem adatbáziskezelő programra van szükséged, mert azok csak csupasz sql kérdésekkel foglalkoznak, és azokat össze is kell álltani valakinek/valaminek.
Neked komplett ügyviteli rendszerre lenne szükséged, így érthető, hogy pár topiclakó kollegának kicsit elkerekedett a szeme a kérdésed láttán.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Panthera
őstag
válasz fordfairlane #2678 üzenetére
Köszi!
És azt lehet valahogy ellenőrizni, hogy a kimentett sql fájl azonos-e a mysql administrator grafikus felületén elkészített mentéssel?
Kettő különböző ~100 MB méretű adatbázist mentettem ki, de mindkettőnél a parancssoros a kisebb 2 MB-al. Ez mitől lehet? Pl. tömörítés? -
Panthera
őstag
válasz fordfairlane #2688 üzenetére
Nem mélyedtem nagyon bele, örültem hogy ez így sikerült. Közben megkérdeztem egy illetékest is (az alkalmazás szempontjából), ő is a text módra fogja a különbséget.
Szerintem meg fogom majd próbálni egy külön környezetben, mit csinál, ha visszaimportálom - az lesz a biztos. (A grafikus felület az akad a tűzfallal, emiatt szórakozok vele.)Köszönöm mindekinek a segítséget!
[ Szerkesztve ]
-
DNReNTi
őstag
Sziasztok,
Tegnap melóban felmerült egy érdekes kérdés. Jó kis cicaharc lett belőle.
Melyik a jobb megoldás?
1. Az objektum adatait több táblában tárolni.
pl: user, user_meta, user_settings, user_log.
Így jobban megoszlik az adat, olvasmányosabb a struktúra, cserébe sok a JOIN.
2: Az objektum összes adatát egy táblában tárolni.
pl: Minden felhasználóval kapcsolatos adat a user táblában.
Így ömlesztve van az egész, de egy sima SELECT-tel elérhető minden.(Én az 1. pont táborát erősítettem.)
but without you, my life is incomplete, my days are absolutely gray
-
-
rum-cajsz
őstag
válasz DNReNTi #2690 üzenetére
Igazából ez nem elméleti kérdés, hanem tervezési. Attól függ, hogy mire fogod használni később a táblát. Ha felosztod külön táblákra, akkor a lekérdezések gyorsabbak lehetnek, illetve az adatírások nem lassítják az olvasást.
Mellesleg ha egy nézetet készítesz a sok tábládra, akkor nem kell mindig a joinokkal vacakolni, elég a nézet nevét használnod. Ha primary keyen kapcsolódnak, akkor az index mentén a join nem számottevő.Nehéz erre tanácsot adni mert ismerni kellene a rendszereteket, és a felhasználási módokat, de ha nagyobb adatmennyiségről van szó (több százezer) akkor én a több táblás megoldást választanám. Ha csak pár ezer felhasználóról van szó, akkor édesmindegy, válaszd azt, ami közelebb áll a lelkedhez.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
DNReNTi
őstag
1-1 kapcsolat persze. A VIEW jó ötlet, eszembe nem volt. Egyébként rosszul tettem fel az eredeti kérdést. Hatékonyabb e, ha egy táblában van? Mert ha csak felesleges az nem gond.
Szerk:
(#2692) rum-cajsz
PK-n vannak összekapcsolva, és igen, elég nagy mennyiség, jelenleg közel 100k felhasználóról van szó.[ Szerkesztve ]
but without you, my life is incomplete, my days are absolutely gray
-
-
Sk8erPeter
nagyúr
válasz DNReNTi #2690 üzenetére
Erre a kérdésre a tárolandó adatok ismeretének hiányában tényleg nem nagyon lehet pontosan válaszolni, DE esetedben már kapásból látszik egy ilyen, hogy pl. user_log, ez már eleve feltételezi, hogy itt több bejegyzés is fog szerepelni, mert elég érdekes napló az, amiben minden korábbi értéket folyton felülírsz. (Az időnkénti tisztítás más tészta, mert az is kell, de nem így. ) Ergo ez már kapásból különválasztást, normalizálást igényel.
Ha a user_settings sok mezőt feltételez, és akár már nem is 1-1 kapcsolat van köztük, akkor megint csak kötelező normalizálni (egyrészt ronda a teleokádott tábla, másrészt kerülni kell a szokásos anomáliákat).
A többi adat széjjelbontása is csomó mindentől függ, de tényleg tervezési kérdés, ha szebb különválasztva, akkor tedd azt, ha nem, akkor ne. Nem kell erőltetni, de a jointól sem kell félni, sőt.Sk8erPeter
-
DNReNTi
őstag
válasz Sk8erPeter #2696 üzenetére
Igen az pont 1:n. Kapkodtam.
Lényeg a lényeg, így összesítve az információkat, nem lesz kevésbé hatékony, ha meg vannak osztva az adatok, így aki ezzel érvel, azt el tudom hajtani.
but without you, my life is incomplete, my days are absolutely gray
-
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.
Én kérek elnézést!
-
dellfanboy
senior tag
mit ajánlotok ha el szeretnék mélyedni a plsql világában? itt egy pl sql tanfolyam megéri a pénzt?[link]
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
Brett001
aktív tag
Sziasztok!
Tökre semmit nem értek a MySQL-hez ezért előre is elnézést a nagyon lamer kérdésért. A lényeg annyi, hogy fut a gépemen egy WAMP 2.4 webszerver localhostként használom. Van egy progi ami létrehoz egy mysql adatbázist és abba töltöget fel adatokat. Egy másik meg kiolvassa ezeket és dolgozik velük. Persze néha elfordul, hogy hibás feltöltés fordul elő ilyenkor a phpMyAdmin progival bele tudok nyúlni, sorokat törölni, átszerkeszteni adatokat én is tudok. Most viszont adódott egy olyan helyzet, hogy szereztem egy másik kiolvasó progit ami a dátumot/időt UNIX_TIMESTAMP formában várja. Az én feltöltőm viszont a dátum időt YYYYMMDDHHSS formában tölti fel. (pl. a mai nap 21:58 igy néz ki 201412092158 az oszlop neve 'datetime'.) No most nekem ezt kéne unix idővé konvertálni, hogy az új progi értelmezni tudja. Azt ugye meg tudom csinálni, hogy phpmyadmin ---> sor módosítás a 'datetime' oszlophoz kiválasztom a UNIX_TIMESTAMP függvényt és indítás. Meg is csinálja. Vagy ha ezt beírom belső parancsként
UPDATE `dbnév`.`táblanév` SET `datetime` = UNIX_TIMESTAMP('20141201000200') WHERE `táblanév`.`station_id` = 'érték'
De ugye a phpmyadmin csak egy rekordot tud egyszerre. Ha több sort bepipálok nem csinálja meg a függvény alkalmazását minden bepipált sorra. Ellentétben pl. a törléssel.
Milyen belső parancsot kell kiadni, hogy az egész 'datetime' oszlop összes rekordját átkonvertálja unix időbe?
"Felkészültség és fegyelem a sorsunk urává tesz." Farell főtörzsőrmester
Új hozzászólás Aktív témák
- Google Chromecast Audio - Új és használt darabok
- Motorola Edge 40 8/256gb - Újszerű, akár beszámítással
- Xiaomi Poco X5 Pro 8/256gb - Újszerű akár beszámítással
- Apple iPhone 12 Pro 128gb Gold - Karcos, kis hiba, akku 85%, Yettel függő, akár beszámítással
- Apple Watch 9 45mm Cellular Silver/Storm Blue M/L - Új, bontatlan, garanciális akár beszámítással