- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- urandom0: Új kedvenc asztali környezetem, az LXQt
- sziku69: Szólánc.
- eBay-es kütyük kis pénzért
- aquark: Jó platformer játékokat keresek!
- gban: Ingyen kellene, de tegnapra
- sh4d0w: Árnyékos sarok
- Elektromos rásegítésű kerékpárok
- skoda12: Webshopos átverések
Új hozzászólás Aktív témák
-
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éntUPDATE `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?
-
#2699
dellfanboy
őstag
dellfanboy
őstag
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]
-
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.
-
#2697
DNReNTi
őstag
Sk8erPeter
#2696
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.
-
#2696
Sk8erPeter
nagyúr
DNReNTi
#2690
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. -
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ó. -
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.
-
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.)
-
#2689
Panthera
őstag
fordfairlane
#2688
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!
-
#2686
Panthera
őstag
fordfairlane
#2678
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? -
bambano
titán
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.
-
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
-
#2676
dellfanboy
őstag
Ispy
#2674
dellfanboy
őstag
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. -
#2675
#68216320
törölt tag
Sk8erPeter
#2667
#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.
-
#2674
Ispy
nagyúr
dellfanboy
#2673
Ispy
nagyúr
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 -
#2673
dellfanboy
őstag
dellfanboy
őstag
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
-
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éter -
#2671
fordfairlane
veterán
Sk8erPeter
#2670
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.
-
#2670
Sk8erPeter
nagyúr
fordfairlane
#2669
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.
-
#2667
Sk8erPeter
nagyúr
#68216320
#2665
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. -
#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?
-
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!
-
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. -
#2655
fordfairlane
veterán
#68216320
#2653
fordfairlane
veterán
-
#2653
#68216320
törölt tag
fordfairlane
#2652
#68216320
törölt tag
válasz
fordfairlane
#2652
üzenetére
MySQL Community Server van feltéve. Ebben nincs Workbench. Tegyem fel azt is?
-
#2650
#68216320
törölt tag
fordfairlane
#2648
#68216320
törölt tag
válasz
fordfairlane
#2648
üzenetére
Az a helyzet, hogy én csak a MySQL 5.6-ot letöltöttem és feldobtam a gépre minden konfigolás nélkül, hogy tudjak Apache/Php5-el offline módon weblapot csinálni. Ahogy rákerestem, nincs is my.ini fájlom a gépen. A mysql könyvtárában van egy my-default.ini. Gondolom ebből kellene készíteni.
Eddig ez fel sem tűnt, mert működik minden phpmyadmin alatt.Szolgáltatásoknál be is van állítva a my.ini útvonala, de ott nincs az adott fájl, csak a default.
Átneveztem és ezt tartalmazza:# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLESHogyan érdemes beállítanom? Csak weblap készítéshez kell, nem futtatok olyan webszervert ami terhelné a legcsekélyebb mértékben is.
-
#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.
-
#2642
bpx
őstag
dellfanboy
#2641
bpx
őstag
válasz
dellfanboy
#2641
üzenetére
pl. február:
where
date_to is null
and trunc(date_from, 'MM') = date'2014-02-01' -
#2641
dellfanboy
őstag
bpx
#2635
dellfanboy
őstag
közbe gondolkoztam és rájöttem, hogy rosszul tettem fel a kérdést.
mert az első kérdésemmel azon id-kat találom meg akik 1.-jén (date from) aktívak 30.-áig (date to)
de én arra vagyok kiváncsi 1 hónapban hány új id lett/szünt meg
tehát kell képeznem egy februári halmazt és egy márciusit. e kettő különbsége adja meg az növekedést/csökkenést.tehát egy olyanre kellene szűrnöm első sorban hogy a date to cella üres(aktív) a date from pedig adott hónapban töltődött ki. és ha ez megvan, akkor nem is kellene a halmazokkal szórakoznom, hisz megvan az adott hónapban 'született' id-k halmaza. amit keresek.
tehát a date from feb1-feb28 között bármilyen dátum, a date to pedig üres
-
#2639
bambano
titán
dellfanboy
#2633
bambano
titán
válasz
dellfanboy
#2633
üzenetére
én a két dátum különbségét venném napban és az alapján válogatnék.
-
#2638
bpx
őstag
supercharley
#2637
bpx
őstag
válasz
supercharley
#2637
üzenetére
akkor itt a buta verzió:
select a1.datum, a1.azonosito, (select sum(a2.darab) from adattabla a2 where a2.azonosito = a1.azonosito and a2.datum <= a1.datum) from adattabla a1
order by a1.datum, a1.azonosito; -
#2636
bpx
őstag
supercharley
#2634
bpx
őstag
válasz
supercharley
#2634
üzenetére
select datum, azonosito, sum(darab) over (partition by azonosito order by datum, azonosito range between unbounded preceding and current row) from adattabla
order by datum, azonosito; -
#2635
bpx
őstag
dellfanboy
#2633
bpx
őstag
válasz
dellfanboy
#2633
üzenetére
where
extract(day from date_from) = 1
and extract(day from date_to + 1) = 1
and trunc(date_from, 'MM') = trunc(date_to, 'MM') -
#2634
supercharley
tag
supercharley
tag
Sziasztok!
Elég kevéssé értek az SQL-hez, és most bele is akadtam egy problémába.
Erről lenne szó:adattábla
---------
dátum Date8
azonosító Character10
db Numeric 5Az azonosító több dátumon is lehet, illetve van is!
A feladat, hogy minden rekorhoz legyen egy olyan plusz
mező, amelyben az adott azonosítóhoz a db
értékét tartalmazza leösszesítve az adott dátumig
az azonosítókra.
Pl.:adattábla
----------
2014.01.01. 0001 500
2014.01.01. 0002 150
2014.01.02. 0001 80
2014.01.03. 0002 55
2014.01.03. 0001 110erdemény
----------
2014.01.01. 0001 500 500
2014.01.01. 0002 150 150
2014.01.02. 0001 80 580
2014.01.03. 0002 55 205
2014.01.03. 0001 110 690Meg tudná mondani valaki ennek a megoldását?
-
#2632
Ispy
nagyúr
dellfanboy
#2631
Ispy
nagyúr
válasz
dellfanboy
#2631
üzenetére
Milyen SQL? Keress valami MONTH, DATEPART szerű függvényt.
-
#2631
dellfanboy
őstag
dellfanboy
őstag
van két olyan oszlopom, hogy date_from és date_to
segítsetek már abban, hogy tudok szűrni, hogy 1 adott hónapot kapjak? próbáltam a beetwen-el de nem jött össze (1 id aktív 30 napon keresztül hónap első napjától az utolsóig)
a 2 oszlopban az idő úgy néz ki hogy évhónap órapercmásodperc -
#2630
PumpkinSeed
addikt
fordfairlane
#2628
PumpkinSeed
addikt
válasz
fordfairlane
#2628
üzenetére
Köszönöm a kisegítést.
-
#2629
lakisoft
veterán
fordfairlane
#2628
lakisoft
veterán
válasz
fordfairlane
#2628
üzenetére
Ez nem csak az említett környezetre hanem az összes MySQL futtató környezetre alkalmazható.
-
#2628
fordfairlane
veterán
PumpkinSeed
#2627
fordfairlane
veterán
válasz
PumpkinSeed
#2627
üzenetére
-
#2627
PumpkinSeed
addikt
PumpkinSeed
addikt
MySQL adatbázist Debian CLI-ből hogy lehet kimenteni?
-
#2625
Kommy
veterán
Apollo17hu
#2623
Kommy
veterán
válasz
Apollo17hu
#2623
üzenetére
Sajnos nem tudom megkérdezni, de most már működik miután beimportáltam sqlite-ból postgres-be most már működik megfelelően.
-
#2624
Apollo17hu
őstag
Apollo17hu
#2623
Apollo17hu
őstag
válasz
Apollo17hu
#2623
üzenetére
Mondjuk ez SQLite, de megerősíti, amit írtam:
"The WITH clause cannot be prepended to the second or subsequent SELECT statement of a compound select." -
#2623
Apollo17hu
őstag
Kommy
#2620
Apollo17hu
őstag
Akitől kaptad, annál működik?
Nekem nagyon kuszának tűnik az egész, bár én eleve nem JOIN-okat használok.
Egy tippem van: elképzelhető, hogy virtuális nézeten (WITH) belül nem lehet virtuális nézetet létrehozni. Sőt, nem is értem, hogy miért van rá szükség, ha a belső virtuális nézetre egy SELECT * FROM kerül...
-
#2622
Kommy
veterán
Peter Kiss
#2621
Kommy
veterán
válasz
Peter Kiss
#2621
üzenetére
")" szintaktikai hibát ír a program
-
Kommy
veterán
Sziasztok,
van egy kapott view kódom és nem jövök rá mi a gond vele:
CREATE VIEW Example_BestLaps_imola_evoraGtc_p45_Limit_30_Offset_0
AS
WITH BestLapTimeHelper AS (
SELECT MIN(LapTime) AS LapTime, PlayerInSession.PlayerId AS PlayerId, PlayerInSession.CarId AS CarId
FROM Lap JOIN PlayerInSession ON (Lap.PlayerInSessionId=PlayerInSession.PlayerInSessionId)
WHERE
Lap.Valid IN (1,2) AND
Lap.PlayerInSessionId IN (SELECT PlayerInSession.PlayerInSessionId
FROM
PlayerInSession JOIN Session ON (PlayerInSession.SessionId=Session.SessionId)
JOIN Players ON (Players.PlayerId=PlayerInSession.PlayerId)
WHERE Session.TrackId IN (SELECT TrackId FROM Tracks WHERE Track='imola') AND
PlayerInSession.CarId IN (SELECT CarId FROM Cars WHERE Car IN ('lotus_evora_gtc','p4-5_2011'))
)
GROUP BY PlayerInSession.PlayerId,PlayerInSession.CarId
)
SELECT * FROM (
WITH BestLapIds AS (
SELECT MAX(LapTimes.LapId) AS LapId FROM
BestLapTimeHelper JOIN LapTimes ON
(BestLapTimeHelper.LapTime=LapTimes.LapTime AND
BestLapTimeHelper.PlayerId=LapTimes.PlayerId AND
BestLapTimeHelper.CarId=LapTimes.CarId)
GROUP BY LapTimes.LapTime,LapTimes.PlayerId,LapTimes.CarId
ORDER BY LapTimes.LapTime
LIMIT 30
OFFSET 0
)
SELECT Name, LapTimes.LapTime, Valid, LapTimes.Car
FROM BestLapIds JOIN LapTimes ON (BestLapIds.LapId = LapTimes.LapId)
) AS tmpHa kiveszem a GROUP BY PlayerInSession.PlayerId,PlayerInSession.CarId utáni rész akkor lefut különben hibát ad
-
Louro
őstag
Sziasztok!
A VB után most a PL/SQL Dev-vel ismerkedek. Itt van lehetőség arra, hogy például egy megadott mappából vegye az összes .csv kiterjesztésű fájlt, majd azokból csak bizonyos mezőket hozzak el és ezen felül a fájlnevet betöltsem egy mezőbe?
VB szkripttel ezt megoldottam, de itt nem találok a neten rá vonatkozó cikket.
Segítségetek előre is köszönöm!
-
l_ági
újonc
Sziasztok!
Telepítettem a PL/SQL program próbaverzióját gyakorlás céljából, még kezdő vagyok a témában, úgyhogy előre bocs az amatőr kérdésért...
Már a belépéskor elakadok, ugyanis kéri a felhasználói nevet és jelszót és nem enged be azzal, amit az Oracle regisztrációnál megadtam. Vagy köze sincs ehhez????Előre is köszi!!
Ági -
drogery
tag
Sziaszok, egy kis segítséget szeretnék kérni. Tud valaki ajánlani, egy jobb ingyenes sql like db szolgáltatót? Annyi kritériumom van, h min 50-100mb tár, sql like query-kkel használható lehessen és legyen java driver. Semmilyen érzékeny adatot nem akarok tárolni rajta, ha az a feltétel, hogy egy index.html ki legyen rakva a tárhelyen az is tökéletes.
-
bpx
őstag
válasz
bambano
#2610
üzenetére
Nem tettem tönkre, ezt egyszerűen így kell leírni, mert sajnos nincs LIMIT. A WHERE előbb van, mint az ORDER BY, a másodikban levő subquery azt jelenti, hogy "olvass fel <4 sort a táblából és rendezd", és nem pedig azt, hogy "kérem rendezés után az első <4 sort".
ez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
Hasonló, de a sorok számára vonatkozó feltételeket speciálisan kezeli, ezek a végrehajtási tervben megjelenő STOPKEY műveletek, amelyek csak addig futtatják a gyerekeiket, amíg el nem érik a megadott limitet. Tehát valóban az történik, hogy úgy kezd neki, mintha az egészet fel kellene olvasni, de 3 sornál megáll. Az adatbázis az egyéb feltételeket is simán mozgatja szintek között, ha szerinte úgy hatékonyabb, azokra nincs külön művelet.
A subquery-t ha lefuttatom magában, nyilván végigmegy 1 millió sorra, hiszen nem lesz ott a külső szűrés, ami leállítja 3 sornál.
-
bambano
titán
persze, hogy nincs különbség, ha a limites átírásoddal pontosan azt a részt teszed tönkre, ami a lényegi különbség a két lekérdezés között.
próbáld ki ezt a két lekérdezést:
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASCés
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk where rownum<4 ORDER BY aru_egysegar DESC) aruk_kivonat
ORDER BY aruk_kivonat.aru_egysegar ASCez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
adjon valaki hitelt érdemlő bizonyítékot, hogy az a query, ahol a belső select 1 millió sort ad vissza, ugyanannyi idő alatt lefut és pontosan ugyanannyira optimális, mint az, ahol a belső select csak 3 sort ad vissza.
szerk: illetve futtasd le a subselecteket önmagában és nézd meg a találati halmaz nagyságát.
-
bpx
őstag
válasz
bambano
#2608
üzenetére
OK, akkor kiegészíteném annyival, hogy Oracle-ben nincs különbség.
SELECT /*+ GATHER_PLAN_STATISTICS */ t.aru_nev, t.aru_egysegar FROM
(SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC)
AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar
Plan hash value: 68470586
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 2 | VIEW | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 3 | WINDOW NOSORT STOPKEY | | 1 | 1000K| 4 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 5 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 1000K| 5 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("T"."SORREND"<4)
3 - filter(RANK() OVER ( ORDER BY INTERNAL_FUNCTION("ARU_EGYSEGAR") DESC )<4)Az első query-t egy az egyben másoltam, a másodiknál a limitet át kellett írnom, mert az itt nincs.
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASC
Plan hash value: 2883829479
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 3 | 3 |00:00:00.01 | 4 |
|* 2 | COUNT STOPKEY | | 1 | | 3 |00:00:00.01 | 4 |
| 3 | VIEW | | 1 | 3 | 3 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 3 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 3 | 3 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(ROWNUM<4)0,01 másodperc, 4 darab blokk érintésével megoldotta mindkettő. Egyedüli látványos különbség, hogy az elsőnél mindenhol 1000K a becsült sorok száma.
A 2 query egyébként nem ekvivalens, rank() helyett row_number()-rel lenne az.
-
bambano
titán
általában a window funkcióknál nem fog, ez igaz, de én nem általában írtam, hanem a konkrét megoldásra.
"egy ilyen egyszerű példában nincs különbség.": ezt az állítást nem ártott volna bebizonyítani, ebben az esetben kiderül, hogy tévedés, és nem készül belőle hozzászólás.
1 millió rekordos teszt adatbázison jól láthatóan gyorsabb a sima subselectes.
test=> explain SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Sort (cost=109649.00..110482.34 rows=333333 width=36)
Sort Key: t.aru_egysegar
-> Subquery Scan t (cost=0.00..60836.36 rows=333333 width=36)
Filter: (t.sorrend < 4)
-> WindowAgg (cost=0.00..48336.36 rows=1000000 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(6 rows)test=> explain SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Sort (cost=0.15..0.16 rows=3 width=36)
Sort Key: aruk.aru_egysegar
-> Limit (cost=0.00..0.10 rows=3 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(4 rows)time psql -d test -c 'SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;'
real 0m0.639s
user 0m0.024s
sys 0m0.016stime psql -d test -c 'SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC'
real 0m0.032s
user 0m0.024s
sys 0m0.004sha kiveszem a subselecteket és azokat hajtom végre, akkor az első megoldás visszaadja az összes rekordot, a második meg csak hármat.
Fentiek alapján melyik lekérdezés a gyorsabb, optimalizáltabb???
"egy ilyen egyszerű példában nincs különbség.": 19.93750-szeres a különbség egymillió tesztrekordon. A teszt végére még volt üres ram a gépben, tehát nem az döntött, hogy az egyiket vinyóról futtatná, a másikat memóriából, minden teszt teljesen befért a ramba.
-
bpx
őstag
válasz
bambano
#2605
üzenetére
Window function használatával sem fog a 20 millió rekordon végigmenni, ugyanúgy ki tudja választani index mentén az első 3 darabot, és egy ilyen egyszerű példában nincs különbség.
Ugyanakkor én inkább használnám az egyszerűbb módszert. A window function akkor lenne hasznos igazán, ha lenne PARTITION BY, de nincs. Ezen kívül a becsült kardinalitás a window functionnel sokkal pontatlanabb, így sokkal nagyobb az esély egy kevésbé hatékony végrehajtási tervre.
-
#2605
bambano
titán
Apollo17hu
#2601
bambano
titán
válasz
Apollo17hu
#2601
üzenetére
vitatnám ezt a "nincs túlbonyolítva" dolgot.
te fogod a teljes táblázatot, lekérdezed, raksz mellé egy rank függvényt, minden rekordjára, meg window funkciót, stb. és visszaadod az allekérdezésből a teljes táblázatot. majd a külső lekérdezésben kiválasztod a három legnagyobbat. ehhez felhasználtál egy csomó sql dolgot, amit nem is biztos, hogy minden sql verzió támogat.ehhez képest az enyémben az allekérdezés kiválaszt három rekordot, nincs semmi elektromos csellentyűcske, és három darab rekordot ad vissza a külső lekérdezésnek rendezésre. ráadásul a három legnagyobbat index-szekvenciális kereséssel is megtalálja az adatbáziskezelő, ha van index az adott mezőre, majd a végén összesen három rekordot kezd el sorbarendezni.
futtasd már le mindkét lekérdezést egy táblán, amiben van 20 millió rekord, indexelve...
-
attis71
tag
válasz
fordfairlane
#2602
üzenetére
Ez már működik.
Ezzel adtál pár ötletet.
Nagyon szépen köszönöm.attis71
-
#2603
attis71
tag
Apollo17hu
#2599
attis71
tag
válasz
Apollo17hu
#2599
üzenetére
Ezt a hibát kapom:
A MySQL mondta: Dokumentáció
#1064 - 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 '(ORDER BY aru_egysegar DESC) AS sorrend
FROM aruk) aruk
WHERE aru.sorrend < 4
OR' at line 3
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
Kapkodtam.
Nem kell erőltetni, de a jointól sem kell félni, sőt.
Új hozzászólás Aktív témák
Hirdetés
- Házimozi belépő szinten
- sziku69: Fűzzük össze a szavakat :)
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Luck Dragon: Asszociációs játék. :)
- Milyen házat vegyek?
- Parfüm topik
- Megérkeztek a Xiaomi 15T sorozatának telefonjai Magyarországra
- Samsung Galaxy A56 - megbízható középszerűség
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- További aktív témák...
- GARANCIÁLIS BONTATLAN MINDEN MACBOOK AIR M4
- Tyű-ha Lenovo Thinkpad X1 Carbon G8 Profi Érintős Laptop 14" -50% i7-10610U 4Mag 16GB/512GB FHD IPS
- AKCIÓ BONTATLAN GARIS IPHONE 16 PRO ÉS PRO MAX MINDEN SZÍNBEN ÉS TÁRHELLYEL 1 ÉV GARANCIÁVAL
- iPhone 17 Air - összes tárhely és szín bontatlan, viszonteladótól független 1év Apple garanciális
- iPhone 13 128GB midnight-black, független + extra tokok
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- Honor X8 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 15 Pro Max 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3067
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
- Új Asus S14 Vivobook Flip X360 Touch 2in1 Ryzen5 7430U 16GB 1TB SSD AMD Radeon Vega7 Win11 Garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest