Hirdetés
- mefistofeles: OTP mobilbank Persely. Jó, de nem jó.....
- Mr Dini: Mindent a StreamSharkról!
- t72killer: Egy gyors töltőteszt
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Fűzzük össze a szavakat :)
- Toomy: Majdnem banki adathalász csalás áldozata lettem.
- Luck Dragon: MárkaLánc
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Samsung Galaxy SmartTag2-esek a tolvajok ellen!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
Új hozzászólás Aktív témák
-
-
Louro
őstag
válasz
bambano
#4197
üzenetére
A HAVING-et általában subselect-tel oldják meg az emberek. Az első kettő az nagyon alap. A 3. feladatnál csak arra voltam kíváncsi, hogy kétségbeesik vagy nem. HAVING simán helyettesíthető. Csak azzal elengánsabb.
Már a 2. olyan kolléga van mellettem, akik több év elemzés után nálunk találkozott a ROW_NUMBER()-rel. Én meg amikor autodidakta módon tanultam, annyira alapnak véltem.
De az se mindegy, hogy mennyi tábla van összekötve. Előző osztályvezetőnk olyan kódot írt, amiben legalább 15 tábla volt LEFT JOIN-nal összekötve. (MSSQL.) Tetű lassú volt. 4-4,5 órát futott. Azzal, hogy szétszedtem 4 részre, 20-30 perc alatt megvolt az eredmény. Semmi mást nem néztem, de van egy olyan érzésem, hogy lehetne performanciát javítani.
Itt arra akarok utalni, hogy nem elég, hogy valaki ismeri a főbb parancsokat, igényesnek is kell lenni és gondolni kell arra, hogy limitált az erőforrás. (A rengeteg temptábláról nem is beszélve. Egy hónapig takarítottam, a GDPR bevezetése előtt.)
Speciális dologkra interjún nem is kérdeztem, mert úgyis ott a gugli. Én is használom, ha elakadok vagy keresek gyorsabb, jobb megoldásokat. Hülyeségnek tartottam mindig, ha interjún valaki nagyon mély ismeretre kérdezz. A jelentkező is lehet tudna olyat kérdezni, amit meg az interjúztató nem tudna :/
-
bambano
titán
ezeket a feladatokat nem mindig értem. pl. életemben nem használtam having-ot, most per pillanat azt se tudom, mire jó. de a gugli ennyire azért a barátom, meg tudom találni, hogy mi az. akkor én most megbuknék nálatok?
vagy volt olyan, hogy az egyik rossz pontot úgy szereztem interjú előtti teszten, hogy nem tudtam kapásból, hogy a postgresql vacuum-ja mikor mit hogy lockol. mer úgy kb. ki a bánatos francot érdekli. ha gondom lesz vele, elolvasom, felfogom és alkalmazom. de erre nincs szükségem, mert oda nem kerültem be, mert nem tudtam fejből a vacuumot.
úgy látom, nem csak sql terén van baj, hanem toborzás terén is...
-
Louro
őstag
válasz
Nicotin
#4191
üzenetére
Szia,
mi nemrég kerestünk embert, akinek egy SELECT, egy JOIN és egy HAVING feladat volt. Kb. 20-ból 1 ment át. Már ennek is örültünk és fel is vettük
De nem is ez a lényeg. Volt olyan, nem is egy, aki emberileg jónak tűnt. Nekik felajánlottam, hogy tolják le az sqlzoo.net oldalt. 2 hét múlva hívja fel a HR-est és beszéljünk újra. Egyik se volt elég motivált, hogy visszatelefonáljon. Pedig az az oldal nagyon jó az alapokra. Volt egy diákunk, aki üresjárataiban 1,5-2 hét alatt kitolta és tudatosan használta. Ha meg elakadsz, a másik programozói tudást tudod fejleszteni, azaz guglizni kell. Rengeteg fórumon mutatnak megoldást. De azért 5 perc után nem érdemes rákeresni
Igaz ez a standard SQL, nem MySQL, de az alap menjen. Ha az alap betonstabil, akkor azzal is megoldod a legtöbb feladatot.
Kísérletezéshez a W3Shools.com/sql se rossz.
-
-
Nicotin
kezdő
Sziasztok abban kérnék segítséget számomra elég nehéz a mysql így nem lenne-e valami anyag kezdőknek ? A sulis közép szintű érettségi feladatokban is az első 3 feladatott sikerül megcsinálnom. Nincs valami megoldás esetleg hogy könnyeben megértsem a dolgokat ? előre is köszönöm.
-
baracsi
tag
Semmi extra, készít egy tömeges SQL-t,amit neked kell lefuttatni, sok ALTER TABLE [séma.táblanév] FORCE; sort fogsz kapni. Azon táblákra, amelyekben van time, timestamp, vagy datetime típusú mező. InnoDB-s perzisztens táblákra vonatkozik, nyugodtan le lehet futtatni a query-t, max nem kapsz semmit vissza.
-
kem
addikt
Sziasztok!
Meg mindig nem vagyok valami nagy DBA de ugy tunik a jelenlegi feladatom kicsit segiteni fog ebben
RDS MySQL 5.6-ot frissitunk 5.7-re, es az Amazon szerint az uzemkiesest drasztikusan le lehet csokkenteni ha a kovetkezo alteraciot vegigtolom az adatbazisokon. A gond csak annyi, hogy nekem ez nagyon magas. Ha valaki csinalta mar vagy erti mirol van szo es nem banja kifejthetne nekem Elore is koszonom a valaszokat!Upgrades to MySQL Version 5.7 Might Be Slow:
MySQL version 5.6.4 introduced a new date and time format for the datetime, time, and timestamp columns that allows fractional components in date and time values. When upgrading a DB instance to MySQL version 5.7, MySQL forces the conversion of all date and time column types to the new format.
...
To find all tables in your database that have datetime, time, or timestamp columns and create an ALTER TABLE <table_name> FORCE; command for each table, use the following query.Query:
SELECT DISTINCT CONCAT('ALTER TABLE `',
REPLACE(is_tables.TABLE_SCHEMA, '`', '``'), '`.`',
REPLACE(is_tables.TABLE_NAME, '`', '``'), '` FORCE;')
FROM information_schema.TABLES is_tables
INNER JOIN information_schema.COLUMNS col ON col.TABLE_SCHEMA = is_tables.TABLE_SCHEMA
AND col.TABLE_NAME = is_tables.TABLE_NAME
LEFT OUTER JOIN information_schema.INNODB_SYS_TABLES systables ON
SUBSTRING_INDEX(systables.NAME, '#', 1) = CONCAT(is_tables.TABLE_SCHEMA,'/',is_tables.TABLE_NAME)
LEFT OUTER JOIN information_schema.INNODB_SYS_COLUMNS syscolumns ON
syscolumns.TABLE_ID = systables.TABLE_ID AND syscolumns.NAME = col.COLUMN_NAME
WHERE col.COLUMN_TYPE IN ('time','timestamp','datetime')
AND is_tables.TABLE_TYPE = 'BASE TABLE'
AND is_tables.TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema')
AND (is_tables.ENGINE = 'InnoDB' AND syscolumns.MTYPE = 6);
-
user112
senior tag
Sziasztok!
Évenként külön Oracle táblában tárolom az adatokat (vevoId, cikkId és ertek).
Hogyan tudok megjeleníteni két-három év adatait egymás melletti oszlopban, úgy hogy egy vevő egy árucikke egy sorban legyen? (évenként különböző cikkeket is vehet a vevő, ezek nyilván külön soba kerülnének.) -
bambano
titán
ilyen mindenhol van.
logolni a mysql naplójába lehet (gondolom, mert azt se ismerem), a próbálkozások helyéről meg a forrás ip cím felvilágosít, azt kernel szinten érdemes logoltatni a beépített tűzfallal.egyébként meg én nem olvasgatnék ilyen logokat, totál időpazarlás, rakás kiskínai erőlködik. ha linuxon futnak a mysql-ek, akkor van rá egy fail2ban alkalmazás, azzal meg lehet csinálni, hogy beállított számú elrontott bejelentkezés után kitiltsa az ip címet a tűzfalban, oszt jónapot.
-
laci06
senior tag
Sziasztok!
Lenne egy SQL, pontosabban MySQL-es kérdésem. Van egy szerverünk, vagyis több is, de van egy a default 3306-os porton, ami mivel az internetről adatokat másolunk rá, nyitva van kifele.
Most észrevettem, hogy valaki elég rendszeresen be próbál jelentkezni rá. Próbálkozik root és user usernevekkel, meg néha teljesen random dolgokkal, pl superman stb.
Nem tudom, hogy szórakozik-e, vagy komolyan gondolja, de szeretném megtudni. A kérdésem az lenne, hogy van lehetőség arra, hogy visszanézzük, hogy milyen jelszavakkal próbálkozik, vagy esetleg elkezdjük menteni őket? Abból legalább tudnánk, hogy ismerjük-e (már ha pl nevünkre, vagy foglalkozásunkra utaló jelszavakkal próbálkozik), vagy valaki random rátalált az IP-re, és arra, hogy ott van egy SQL szerver, és csak random próbálkozik, gyakorol, szándék nélkül. Tapasztaltatok már ilyet régebben?
Köszönöm!
-
#4181
bambano
titán
Apollo17hu
#4180
bambano
titán
válasz
Apollo17hu
#4180
üzenetére
"Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód": teljesen megnyugodtam
-
#4180
Apollo17hu
őstag
bambano
#4179
Apollo17hu
őstag
válasz
bambano
#4179
üzenetére
Nem, vagyis én próbálok mindig a legjobb tudásom szerint kódolni, de mezei kontrollerként nem értek az optimalizáláshoz. Egyébként azt a 20 darab allekérdezést össze tudnám gyúrni 5-6-ba, de akkor egy potenciális jövőbeli hibakeresés sokkal tovább tartana (nekem is, de méginkább olyasvalakinek, aki nem ismeri a kódot). Az én szemszögemből az lenne a legegyszerűbb, ha egy táblából tudnék leszedni mindent, de a mostani mókolás is azért kellett, mert nincs IT erőforrás a fejlesztésekre.
Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód.
-
#4179
bambano
titán
Apollo17hu
#4178
bambano
titán
válasz
Apollo17hu
#4178
üzenetére
nem merült fel, hogyha 20 darab 800 soros allekérdezés van összerakva, akkor az egész totálisan rosszul van megtervezve?
-
#4178
Apollo17hu
őstag
Apollo17hu
#4174
Apollo17hu
őstag
válasz
Apollo17hu
#4174
üzenetére
Kollégámmal közösen megoldottuk.
Volt egy sanda gyanúm, hogy az új allekérdezéseken belül kell keresni a hibát, és beigazolódott. Ezek az új allekérdezések egyenként kb. 800 sornyi programkódból állnak, rengeteg tábla és allekérdezés alkotja őket. Van egy nagyobb saját sémás tábla is, ami csak kiegészítő adatot tartalmaz. Ezt kommenteztem ki, és lefutott a teljes kód. Ezzel az infóval kollégám egy egyszerű use_hash hintet rakott oda, ahova kellett, és így a saját sémás táblával együtt is 4 percen belül fut a teljes kód.
Az a fura, hogy amíg a 800 soros allekérdezéseket külön-külön futtattuk, nem "borult meg" a végrehajtásuk, viszont a teljes kódban már igen.
-
válasz
bambano
#4176
üzenetére
Az adatbázisban int-ek az adatok, de ahol 0 a beérkező hívás, ott nincs értelme megválaszolási arányt számolni, ezért szeretnék az arányszám helyett 'N/A' string-et kiíratni.
Közben sikerült megoldanom
CASE WHEN CAST(app.CallsOffered as INT) = 0 THEN 'N/A'
ELSE CAST(app.CallsAnswered*1.0/CallsOffered as VARCHAR) end as AnswerRateKöszönöm a segítséget
-
bambano
titán
szerintem nem jó irányból közelítesz.
ha egy mezőben szöveg is lehet, akkor az nem lehet int. tehát vagy "n/a"::stringet kell visszaadnod, vagy stringgé konvertált számot. tudomásom szerint olyat egyetlen sql adatbáziskezelő se tud, hogy egy oszlop az egyik sorban string, a másikban meg szám. -
Sziasztok!
Van egy olyan problémám, hogy egy iif vizsgálatnál, ha a vizsgált mező értéke 0, akkor N/A karaktert szeretnék a cellába íratni, azonban olyan konverziós hibával elszáll a select, konkrétan nem tudja az N/A-t int-té konvertálni. De hát én nem is szeretném. Valószínűleg valami implicit konverzióról van szó, de hirtelen nem tudom a megoldást rá. Remélem valaki már találkozott hasonlóval.
Ez lenne a vizsgálat:
iif(CallsOffered=0,'N/A',CallsAnswered/CalllsOffered) as AnswerRateElőre is köszönöm a segítséget
-
#4174
Apollo17hu
őstag
bambano
#4171
Apollo17hu
őstag
válasz
bambano
#4171
üzenetére
Volt korábban ugyanezzel a kóddal memóriaprobléma, de az egyértelmű volt, mert 15 perc után hibaüzenettel leállt. Szerencsére rájöttünk az okára (kb. az volt, hogy a 20 allekérdezés miatt 3^20 szorzót kapott a memóriában elfoglalt mérete, de extra kötésekkel, ezt áthidaltuk).
Temp tábla sajnos nem játszik. Maga a keretrendszer úgy néz ki, hogy különálló sql-eket tárolunk, amelyeket egy alkalmazás minden nap meghív, lefuttat, az eredményt pedig Excelbe másolja. Nincs lehetőség egymásra épülő kódrészletek megadására.
@bpx: Jogos, fejből írtam, de élesben jó helyre raktam a hintet. Ezt a materialize-t még kipróbálom, mert tényleg annyira lenne csak szükség, hogy külön-külön meglegyen az allekérdezések eredménye, utána már 2 másodperc alatt kiszámolja.
-
#4173
bpx
őstag
Apollo17hu
#4170
bpx
őstag
válasz
Apollo17hu
#4170
üzenetére
Persze, mert a hintet nem oda kell rakni, hanem közvetlenül a SELECT után.
WITH
t1 as (...),
t2 as (...),
...
t20 as (...)
SELECT /*+ no_merge (t1 t2 ... t20) */ ...
FROM
t1,
t2,
...,
t20,
() as tx
WHERE
tx.mezo = t1.mezo(+) AND
tx.mezo = t2.mezo(+) AND
...
tx.mezo = t20.mezo(+)Vagy bele az inline view-ba:
WITH
t1 as (SELECT /*+ NO_MERGE */ ...),
t2 as (SELECT /*+ NO_MERGE */ ...),
...Ha azt akarod, hogy gyűjtse ki tempbe az egyes CTE-ket, akkor meg MATERIALIZE hint, pl.:
WITH
t1 as (SELECT /*+ MATERIALIZE */ ...),
t2 as (SELECT /*+ MATERIALIZE */ ...),
...De ez még mindig csak találgatás, plant kellene nézni futásidejű statisztikával.
-
#4172
Ispy
veterán
Apollo17hu
#4170
Ispy
veterán
válasz
Apollo17hu
#4170
üzenetére
Ez nem végtábla, hanem futásidőben rakja össze az sql szerver, aminek az outputja egy tábla, valahogy így....
select *
from dbo.fuggveny_neve(bemeno param1, param2,...) -
#4171
bambano
titán
Apollo17hu
#4170
bambano
titán
válasz
Apollo17hu
#4170
üzenetére
erőforrásokat nem nézted? lehet, hogy valamelyik elfogy. memória, lockok, stb. postgresql-hez értek, abban van ilyen.
másik ötlet: temporális táblába nem érdemes leválogatni a lekérdezéseket?
-
#4170
Apollo17hu
őstag
Ispy
#4168
Apollo17hu
őstag
Az a gond, hogy nem végtáblában van szükségem az eredményre, mert egy automatizmus a további feldolgozás során használja.
@bpx: Próbálkoztam a NO_MERGE hinttel, de egyelőre sikertelenül.
A kód egyébként kb. így néz ki:
WITH
t1 as (...),
t2 as (...),
...
t20 as (...)
SELECT ...
FROM /*+ no_merge (t1 t2 ... t20) */
t1,
t2,
...,
t20,
() as tx
WHERE
tx.mezo = t1.mezo(+) AND
tx.mezo = t2.mezo(+) AND
...
tx.mezo = t20.mezo(+)Próbáltam LEFT JOIN szintaxisra is átírni a (+) kötéseket, de az sem segített.
A WITH-del lehet probléma? Azt olvastam, hogy még segít is az optimizer-nek, mert a legtöbb esetben előbb külön-külön számítja ki a WITH-ben lévő allekérdezések eredményét, és csak utána használja őket.Hogy érthető legyen: mondjuk t3-at, t7-et és t8-at cseréltem ki. Külön-külön minden t tábla minimális idő alatt lefut, néhányszáz sort eredményeznek. Ha csak t3-at (vagy csak t7-et vagy csak t8-at) cserélem ki, akkor 1 perc alatt lefut a kód. Ha már két táblát is kicserélek, akkor nem.
Sőt, ha lebutítom így a kódot:WITH
t3 as (...),
t7 as (...)
SELECT ...
FROM
t3,
t7,
() as tx
WHERE
tx.mezo = t3.mezo(+) AND
tx.mezo = t7.mezo(+)már ez sem fut le. Tehát a 3 új allekérdezés valahogy "összeakad", pedig <1 perc a futási idejük külön-külön.
-
#4169
bpx
őstag
Apollo17hu
#4167
bpx
őstag
válasz
Apollo17hu
#4167
üzenetére
Mindenki keresi az univerzális silver bulletet, de ilyen nincs.
Ha pl. az szeretnéd, hogy az optimizer ne fejtse ki és alakítsa át ezeket, akkor használhatod a NO_MERGE és NO_UNNEST hinteket attól függően, hogy az allekérdezés az csak inline view vagy tényleg subquery.
-
#4168
Ispy
veterán
Apollo17hu
#4167
Ispy
veterán
válasz
Apollo17hu
#4167
üzenetére
Csinálsz egy table valued függvényt és merge raksz össze vele egy output táblát.
-
#4167
Apollo17hu
őstag
Apollo17hu
őstag
Nagy altalanossagban van megoldas (hinteles?) arra, ha van pl. 20 db allekerdezesem, ami egyenkent 200-300 rekordot ad vissza, kulon-kulon 1-60 masodpercig fut, de ha osszekotom oket (a megfelelo mezok menten), akkor elszall az egesz, es egy ora alatt sem fut le. Konkretan van egy ilyen, 5 percen belul futo monstre kodom, aminel 3 allekerdezest lecsereltem, es ez tortent vele. Sajnos plant nem tudok olvasni, ezert altalaban lenne jo vmi tipp, hogy merre induljak el.
Koszi! -
Ispy
veterán
Egy technikai jellegű kérdésem lenne: átköltöztem új laptopra és én hülye megpróbáltam az SSMS-ben tárolt registered servereket átrakni az új gépre export/import funkcióval, de azt írja ki, hogy a kulcs nem használható a megadott államban, ráadásul annyiszor, ahány szerver volt és ez minden megnyitáskor fel is jön. Szóval a kérdés az lenne, hogy vajon ezt az üzenetet meg lehet szüntetni valahogy? Olyan, mintha beragadt volna valahol importálás közben a dolog és mindig megpróbálná befejezni, de nem tudja.
-
zek47
csendes tag
válasz
sztanozs
#4154
üzenetére
Köszönöm!
Egyébként nem akarok beavatkozni a gazdaprogram és az adatbázis kapcsolatába, csak elszedni az adatokat (könyvjelzők, logok stb.), majd a gazdaprogrammal törölni a listát. Journal fájl van, akkor is, ha a program nem fut. Lehet azért, mert az Android automatikusan indítja a programot, és sosem állítja le teljesen.
-
sztanozs
veterán
1-2) az adatbázis fájlban nem marad, de az SQLite nem igazán szereti a konkurens használatot.
a) ha az adatbázi fájl nincs nyitva más által, akkor nincs journal fájl sem és mindent kimásol.
b) ha lehalt az eredeti program és vannak bent ragadt módosítások, de nem korrupt az adatbázis, akkor az adatbázis megnyitáskor azokat végrehajtja és utána mindent kiír
c) ha korrupt az adatbázis, akkor a sémát és az olvasható adatokat is kiírja, de az sql dump vége regy rollback utasítás lesz. Ha ezt kézzel átírod egy commit-ra, akkor az adatbázis-t az aktuálisan olvasható adatokkal vissza tudod állítani.
3) szvsz nincs. Amúgy ez nem "kinyeri" az adatokat, hanem az egész adatbázist és a benne található adatokat és a sémát SQL utasításokká konvertálja. Az adataid eddig is megvoltak, csak máshogy tudsz hozzájuk férni. Ha csak az adatok kellenek, akkor inkább exportálj, de dumpolj: [link]Bónusz: Azért használnak ilyneket, mert ezekhez vannak sztenderd könyvtárak és gyakorlat, míg a szöveges fájlok (főleg ini) feldolgozását (és hibakezelést) kézzel kell megoldani.
-
válasz
user112
#4151
üzenetére
igen, mert ilyenkor az aliasokat párhuzamosan értékeli ki az sql szabvány szerint, ergo amire hivatkozol, az akkor még nem létezik. úgy kell csinálnod, hogy miután összeadtad az 5 meződet, és elnevezted, köré írsz egy másik selectet is, és abban már használhatod a belső select aliasát. ez azért lehetséges, mert a klazuák között kötött kiértékelési sorrend van:
select darab, darabx2 (from select count(*) as darab from tabla); -
updog
őstag
válasz
user112
#4151
üzenetére
Nem tudsz ugyanazon a queryn belül aliasra hivatkozni. Rakd az egészed még egy selectbe.
--Eredeti:
select (1+2+3+4+5) as osszeg from dual;
--Invalid identifier-t ad:
select (1+2+3+4+5) as osszeg, osszeg+5 from dual;
--Megoldás:
select osszeg, osszeg+5 from(select (1+2+3+4+5) as osszeg from dual);Nyilván másik aliassal (mezővel) is így működik, nem csak konstansokkal:
select osszeg, osszeg+ertek from(select (1+2+3+4+5) as osszeg, 5 as ertek from dual); -
zek47
csendes tag
Üdv mindenkinek! Nem vagyok SQL felhasználó, épp csak belenéztem az alapokba. Különböző programok (pl. böngésző, android rendszer) SQLite adatbázisokban tartják az adataim, amiket szeretnék általam felhasználható, szöveges formában kinyerni. Kérdéseim: 1. Az sqlite3 .dump utasítás minden információt kimásol, vagy marad még valami elrejtve az adatbázis fájlban? 2. Ez az utasítás a csatolt journal fájt is feldolgozza? 3. Van esetleg jobb mód az adatok teljes körű kinyerésére?
Bónuszként örülnék, ha elmondanátok, az ilyen egyszerű, kis elemszámú adattárolási feladatokra, javarészt szöveges adatokhoz, a fejlesztők miért használnak adatbáziskezelőt és bináris fájlformátumot valamilyen szöveges formátum (pl. json, hagyományos ini) helyett.
Köszönöm.
-
sztanozs
veterán
válasz
bambano
#4148
üzenetére
ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz
Elméletileg pont fordítva. A NOT IN-hez kell iterálni, az NOT EXISTS anti-joinra konvertálható (csak ebben a formában szebb).Analyse jól írja, mert tényleg pont fordítva van, mert az exists és a left join + null is anti-joinra van optimalizálva, a not in pedig hashed subplan (mert az IN értéket és null-t is visszaadhat, ezért kétszer fut az iteráció - ki elemszámnál ez nem probléma, de nagy elemszámnál már lesz különbség, ráadásul a subplan miatt cache problémák lehetnek).
EXPLAIN ANALYZE
It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows. -
bambano
titán
válasz
sztanozs
#4146
üzenetére
megnéztem rendesebben a kérdést, és nem látom értelmét bemásolni az eredményt.
az explain és az explain analyze egymáshoz képest fordított eredményt hoz. az explain szerint a not in 4x gyorsabb, az explain analyze szerint meg az exists gyorsabb.ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz, ami a fő selectben van. egyébként pedig a postgresql-nél ez a probléma régebben felmerült, úgy látom, hogy a query plannere fel van rá készítve és jó eredményt hoz.
-
#4144
I02S3F
addikt
Apollo17hu
#4128
I02S3F
addikt
válasz
Apollo17hu
#4128
üzenetére
Köszönöm szépen!
-
bambano
titán
válasz
sztanozs
#4141
üzenetére
explain select * from customer where id not in (select customer_id from <anonimizálva>);
QUERY PLAN
---------------------------------------------------------------------------------
Seq Scan on customer (cost=1174.57..1372.72 rows=3366 width=243)
Filter: (NOT (hashed SubPlan 1))
SubPlan 1
-> Hash Join (cost=395.85..1134.83 rows=15895 width=4) -
#4138
SUPREME7
őstag
Apollo17hu
#4137
SUPREME7
őstag
válasz
Apollo17hu
#4137
üzenetére
Áhh, ennél sokkal bonyolultabb találatokat dobott a gugli, de nem sikerült összesakkozni, rá kéne gyúrni ilyen "komplexebb" lekérdezésekre, csak az a baj ritkán kell
Hálás köszönetem -
SUPREME7
őstag
Sziasztok, segítségre lenne szükségem.
Van 3 táblám,
Nyereményjátékok | résztvevők | nyertesek
Szeretném azokat a nyereményjátékokat lekérdezni amiken X részt vett, de nem nyert. A 3 táblát összeköti a nyereményjáték azonosítója.
Jelenleg ez "sima ügy", hogy megvan, hogy melyik nyereményjátékokon vett részt, hogy kellene kiegészítenem, hogy csak azokat listázza amiken részt vett, de nem nyert? Tehát a nyertesek táblát még valahogy bele kéne vonni, hogy ott létezik-e adott user, adott játék azonosítóval. De ez már nekem sok SQL-ből
SELECT nyeremenyjatekok.* FROM resztvevok INNER JOIN nyeremenyjatekok ON nyeremenyjatekok.id=resztvevok.jid WHERE resztvevok.user=? -
#4134
bpx
őstag
dellfanboy
#4129
bpx
őstag
válasz
dellfanboy
#4129
üzenetére
Ez nem SQL, hanem PHP probléma.
$tagid, $autoid helyett $megrendelo_id, $autok_id változókat használsz a query-hez, és nem a CURDATE()-tel van baja, hanem az üres változók miatt a "(, , CURDATE())"-tel.
-
#4133
dellfanboy
őstag
velizare
#4132
dellfanboy
őstag
válasz
velizare
#4132
üzenetére
lefutott
Finished executing script
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
autok_id int(11) NO MUL NULL
megrendelo_id int(11) NO MUL NULL
kolcsonzes_kezdete date NO NULL
kolcsonzes_vege date YES NULL
fizetendo_osszeg int(11) YES NULL
megjegyzes varchar(45) YES NULL
Operation completed successfully -
#4132
velizare
nagyúr
dellfanboy
#4131
válasz
dellfanboy
#4131
üzenetére
fura. futtasd le kérlek ezt a db-ben:
describe kolcsonzes; -
#4130
velizare
nagyúr
dellfanboy
#4129
válasz
dellfanboy
#4129
üzenetére
kéne az "error uzenet".
-
#4129
dellfanboy
őstag
dellfanboy
őstag
hello
lenne egy mySql kerdesem. adott a script 3 oszloppal, es a mai datumot szeretnem beszurni mint harmadik oszlop.
viszont error uzenetet kapok a curdate-re de nem jovok ra mi a hiba.
<?php
include 'library.php';
$link = getDb();
$create = false;
if (isset($_POST['create'])) {
$tagid = mysqli_real_escape_string($link, $_POST['megrendelo_id']);
$autoid = mysqli_real_escape_string($link, $_POST['autok_id']);
$query = sprintf("INSERT INTO kolcsonzes (megrendelo_id, autok_id, kolcsonzes_kezdete) VALUES (%s, %s, CURDATE())", $megrendelo_id, $autok_id);
mysqli_query($link, $query) or die(mysqli_error($link));
$create = true;
}
?>van vkinek vmi tippje mit benazhatok?
-
I02S3F
addikt
Meg is válaszolom a kérdésem. (A MySQL dokumentációjában nem igazodtam ki, de a W3schools weboldala egy egyszerű áttekintést ad. Ott találtam rá a válaszra.)
Ez sima alias azért, hogy rövidítetten lehessen hivatkozni egy "hosszú" nevű táblára. Plusz trükk, hogy ugyanazt a táblát két aliassal látták el, hogy a két tábla között műveletet lehessen végezni.Javítsatok, ha rosszul gondolom!
-
I02S3F
addikt
Sziasztok!
A következő a szekció címe, amit mysql-ben tanulok: "Ugyanazon tábla többszörös használata". Az alább leírt példakódot nem értem, magyarázatra szorul, ezért kérlet titeket nevezzétek meg, hogy mi ez, hogy rákereshessek a neten részletesebb magyarázatért.
SELECT t1.helysegnev, t2.helysegnev, t1.lakossag, t2.lakossag
FROM telepules AS t1, telepules AS t2
WHERE t1.lakossag=t2.lakossag AND t1.helysegnev<t2.helysegnev
ORDER BY 3;- Mit csinál/jelent a pont ebben a kifejezésben "t1.helysegnev"?
- Azért van kétszer a FROM után a telepules tabla atnevezve, hogy műveletet tudjuk rajta végrehajtani ugyanazon táblán (pl.: összehasonlítás)?
- A t1 egy osztály, azért a pont?
- Tudnátok linkelni olvasnivalót, vagy hogy mire keressek rá, hogy megértsem ezt? -
#4125
Apollo17hu
őstag
kw3v865
#4122
Apollo17hu
őstag
válasz
kw3v865
#4122
üzenetére
Így?
SELECT tabla.mezo
,substr(tabla.mezo, instr(tabla.mezo, '"ref"=>""') + length('"ref"=>""')) relevans_adattartalom
FROM (SELECT 'asfasf saf"ref"=>""ez kell' mezo
FROM dual
UNION
SELECT 'asfasf ssadfalksijdfkeefaf "ref"=>""ez is kell, de ez hosszabb' mezo
FROM dual) tablaSubstr utolsó paraméterét elhagyva a mező utolsó karakteréig mindent leválogat. Ha nem jó, akkor mindenképp kell egy ismérv/logika, ami meghatározza a releváns karaktersorozat végét.
-
-
kw3v865
senior tag
Sziasztok!
PostgreSQL-t használok és egy olyan kérdésem lenne, hogy egy adott mezőből (varchar) kellene kiszedni egy stringet, amelynek a pontos hossza nem minden eesetben ugyanannyi, és a pozíciója sem fix, azaz nem mindig egy adott sorszámnál kezdődik és végződik. Csak azt tudom, hogy a számomra szükséges rész mindig így kezdődik:"ref"=>"" (az idézőjelekkel együtt)
A > utáni idézőjelek közötti rész az, ami változó és számomra releváns, de nem tudom, hogy hány karakter hosszú.Az addig okés, hogy kiválasztottam azokat, amelyek tartalmazzák a szükséges részt, így:
LIKE '%"ref"=>"%"
Viszont ebben az oszlopban még mindig sok felesleges infó található. A cél az lenne, hogy a felesleges karakterek kiszűrjem, azaz csak azt tartalmazza az eredmény, ami a kacsacsőr utáni két időzőjel között helyezkedik el. Van valami ötletetek miként lehetne ezt megoldani? -
xTREem
tag
Sziasztok!
Python37-sqlite3 kombóval dolgoznék, de az istennek nem megy a magyar rendezés.
SQLiteSpy-ban sima ügy a lekérdezés 'COLLATE systemnocase' megoldással, ami teljesen jól működik, ugyanakkor python alatt egy 'no such collation sequence: systemnocase' hibaüzenetet ad.
Értem én a hibaüzenetet, rendben is van, de mi az egyszerű megoldás?Válaszotokat köszönöm!
-
Zalanius
tag
válasz
Klub19111
#4117
üzenetére
Összekapcsolás helyett inkább bontás meg átszervezés kell ide, például a Tagok munkalap felbontása -> [Klub]; [Személy]; [Klubtagság] táblákra stb., aztán a Büntetést nyilván egy konkrét teremfoglalásra kell terhelni. Ha rögzített idősávok vannak, akkor azoknak is kell külön tábla, és így tovább. Egy ilyen sémát pikkpakk felír itt bárki, de akkor már nem valamilyen elnagyolt xlstáblából érdemes indulni, ahol a kevésbé fontos részletek hiányoznak, hanem pontosan összeszedve a fogalmakat, igényeket, különben nem éritek el azt a célt, hogy az adattár egyértelmű és áttekinthető legyen, és marad a toldozás-foltozás.
De ez csak az egyik rész. "Ingyenes" adatbáziskezelők akadnak (sqlite, sql express, egyebek), bár üzemeltetni is kell ezeket valahol / valahogy. Oda aztán be is kell tölteni, úgymond migrálni a jelenlegi exceles állapotot, ami nem feltétlen lesz bárki által kivitelezhető. Kínálná magát egy átalakítás Access használatával, egy kicsit az Excelre hasonlító felületen, de az meg nem is annyira ingyenes. Az SQLite például igen barátságosan elfut szinte bármilyen kávédarálón, de valamilyen felhasználói felület azért kellene "fölé". Ezért a felhasználók száma is egy szempont, meg a felhasználás helye (csak lokális vagy valamilyen felhős megoldás kell). Ezek csak az első körös megjegyzések, ha olvassa majd más, hozzáírhat még vagy fél tucatnyit.
Röviden: ez egy első látásra könnyű feladat, ami villámgyorsan el tud durvulni, és hirtelen költségek is lesznek. A kérdés: akkora már az adatmennyiség, és annyira kritikus is a helyzet, hogy megéri áldozni ezekre?
-
Klub19111
újonc
Üdvözlet a fórumnak!
Excelben van egy nyilvántartásunk, de most már sok probléma van vele, mert sokan jönnek-mennek, és akik vannak, azok se minden hónapban jönnek.
Pláne most kitalálták, hogy havonta kell terembeosztást csinálni, azzal is többet kell foglalkozni.Próbáljuk excelben megoldani, de volt, aki szerint ehhez sql-es segítség kell.
Feltöltöttem egy lebutított excel fájlt, csak a négy fontosabb táblázatot hagytam meg, az lenne a jó, ha valahogyan össze lehetne kapcsolni őket, hogy ne legyen névelírás és más gond.
Előre is köszönök minden ötletet, hogyan lehetne megoldani.
Csak Excelünk van, sql-ben valamilyen ingyenes programra lenne szükségünk.
-
martonx
veterán
válasz
kezdosql
#4112
üzenetére
Ember, ezért küldtem konkrét sql scriptet, amiben a végdátum NULLABLE. Azaz nem kell megadni, majd akkor megadod, amikor valóban végetért.
Könyörgöm, tanulj már meg végre SQL-ezni, és tereld már a szakmaiság, és a konkrét megoldás felé magadat, a rózsaszín ködben papíron rajzolgatás helyett, mert ez így borzalmas.
Idióta vádaskodások, belemagyarázások helyett. -
#4114
Apollo17hu
őstag
kezdosql
#4112
Apollo17hu
őstag
válasz
kezdosql
#4112
üzenetére
Mindkét megoldásnak van létjogosultsága. A te verziód akkor lenne használható, ha minden egyes napra generálnál egy rekordot, ami a napra vonatkozó aktuális állapotot mutatja. Intervallumok használatával viszont egy csomó erőforrást megspórolsz. Csak akkor van szükség új rekordra, ha valamelyik mező adattartalmában változás történik.
-
válasz
kezdosql
#4112
üzenetére
A végdátum mindaddig 9999.12.31,amíg adott személy, adott szervezethez tartozik, ha átigazol, akkor ezen a rekordon kap egy végdátumot, majd egy új rekortban a végdátum +1 nap kezdeti dátummal kerül a másik csapathoz (ha nincs szünet a két csapattagság között). Így egy mérkőzésnél pl. elég csak a mérkőzés dátumát, és a játékosok ID-ját megadni, a fenti törzstáblából már levezethető, hogy melyik csapat mérkőzött egymással.
-
kezdosql
tag
Tisztelt Forum!
En azert jottem ide, hogy informaciot kapjak, es tovabbra is a tenyekre akarok fokuszalni es logikus megoldast keresni.
Ha valaki szakembernek tartja magat, akkor orulnek, ha a logika es realitas alapjan reagalna.
Ami a tablakat illeti, mindenki, aki sertodotten valaszolt, hasonlo megoldast javasolt, mint amin en gondolkodtam.
A lenyeges kulonbseg az, hogy allandoan kezdet-veg datumokra kaptam javaslatokat, ami szerintem nem jo, mert minden datumot csak utolag lehet tenykent kezelni.
Tovabbra is ebben latom a lenyeges kulonbseget, es nagyon nem ertem, hogy amikor a legutobbi javaslatom egy datum+szemely+szervezet alapjan esemeny segedtabla bevezetese volt, miert jonnek folyamatosan tamadasok, hogy szemely+szervezet+kezdodatum+vegdatum kell, amikor egyertelmu, hogy a vegdatum csak feltetelezett, az barmikor valtozhat.
-
martonx
veterán
válasz
kezdosql
#4109
üzenetére
Te meg beláthatnád, hogy segíteni próbáltam, de akkor inkább hagyom. Hidd el, lehet papíron rajzolgatni, meg azt mondani, hogy ez, az lényegtelen, aztán a papíron rajzolt valamiket úgyis SQL-ben kell megvalósítanod - ha egyáltalán megvalósíthatóak (persze csinálhatod papíron is, csak az senkit nem fog érdekelni, ez esetben ebben a topikban is kár az időnket rabolnod tovább).
Eddig az volt a baj, hogy semmi konkrét segítséget nem kaptál, most meg az a baj, hogy kaptál. Részemről én itt szálltam ki. Sok sikert!
-
kezdosql
tag
válasz
martonx
#4107
üzenetére
A helyedben belatnam, hogy nem programrol, hanem tablakrol es kapcsolatokrol beszelunk, es mivel en vizualis tipus vagyok, rajzolgatok.
Raadasul eleg a megnevezes, es nem kell szorakozni a tipusokkal, amirol egyreszt fogalmam sincs, hogy adott verzioju mssql mi a nyavalyat kovetel meg es milyen formaban es milyen hossz kell neki - mind lenyegtelen, az ID, a szoveg es a datum mezo a lenyeg, azok meg egyertelmuen kiderulnek a megnevezesekbol.Amugy eleg erthetoen beirtam a semat, konnyen lehet latni a kapcsolatokat, de majd pontositom, hogy ti is megertsetek.
Nekem egy oldalon kell latnom a tablakat, kozottuk a kapcsolatokat, az akarhanyszaz soros create parancssorbol nehez kihamozni, mi hol van es mivel fugg ossze.
Ha az sql-hez ertes azt jelenti, hogy tobb szaz create.. parancssort beirsz es a vegen raboksz valamire, hogy ezt innen veszem, akkor valoban nem ertek sql-hez, nekem le kell rajzolnom a tablakat es memorizalnom kell, hogy melyik tablaban miket kapcsolok ossze. A hosszu lista nekem nem mond semmit, amig nem rajzoltam le a sok kis (nagyobb) teglalapot.
Most sajnos komolyabb gondokkal kel foglalkoznom, de hamarosan jovok a listaval.
-
martonx
veterán
válasz
kezdosql
#4105
üzenetére
Ez így totál parttalan. Megmutatom miről beszélek, most hogy legalább minimum konkrétumot már kihúztunk belőled. A HELYEDBEN én valahogy így állnék neki az egész beszélgetésnek:
Sziasztok, foci mérkőzéseket, meg egész szezonokat, bennük minden létező eseménnyel szeretnék adatbázisban lemodellezni. Jelenleg itt tartok: sqlfiddle példa (egyszerűség, és a példa adatok minimális száma miatt nem szórakoztam Foreign keyekkel)
Az a problémám, hogy...
Amíg nem sikerül a kérdéseidet ilyen formában megfogalmazni, kár is a fentieknél konkrétabb válaszokat várnod.
-
Ispy
veterán
válasz
kezdosql
#4105
üzenetére
A csapatok, ugy latom, egyertelmuek szamodra.
Számomra az egész egyértelmű, csak arra próbálunk rávezetni, hogy jó lenne ezt az egészet, ami már megvan SQL táblákba foglalni és azt felrakni ide.
Az elso ket kategoria mindig adott csapathoz tartozik, az utolso mindig fuggetlen.
Igazából tökmindegy. Kell egy személyek tábla, aminek szintén van ID-ja (meg egyébként minden táblának rendelkeznie kell elsődleges kulccsal). Kell egy csapat tábla és kell egy csapattagok tábla, ami tartalmazza, hogy melyik személy meddig volt a csapat tagja, vagy melyik csapatnak még a tagja.
En a "flag"-et nem ertem, meg sose hallottam rola.
Egy szimpla bit, igen/nem, mindegyiknek egy: játékos, edző, bíró.
Én itt kiszálltam, amíg nincsenek kész táblák és azok kapcsolatai felrakva ide...
-
kezdosql
tag
Esemény lehet egy mérkőzés, egy átigazolás.
Minden esemeny, ami datumhoz kotheto tortenes.
Kezdodik a csapatok kereteivel, annak jovahagyasaval, majd azon belul kijelolik, hogy kik vannak akezdo csapatban es kik a potencialis cserek, majd a meccsen kiderul, kik voltak a tenyleges cserek, stb. mind-mind esemeny.Ezt a sok csapat és sok személy dolgot meg nem értem vagy te nem érted a relációs adatbázis működését.
Szerintem erted, csak nem akarod elfogadni.
A csapatok, ugy latom, egyertelmuek szamodra.
A szemelyek pedig az emberek, akik adott idopontban lehetnek jatekosok, edzok vagy birok.
Az elso ket kategoria mindig adott csapathoz tartozik, az utolso mindig fuggetlen.En a "flag"-et nem ertem, meg sose hallottam rola.
Sokkal egyszerűbb lenne az élet, ha feldobnád ide a táblákat
"Feldobtam", a kerdes a kapcsolatok osszehozasa, mert id szerint csak a csapatok azonosithatok, a szemelyek eseteben esetenkent kell a statusza, hogy jatekos, edzo vagy biro.
Ezzel van problemam, ahogy te is irtad, "atfedes lehet", ezt kell valahogy kezelni. -
Ispy
veterán
válasz
kezdosql
#4101
üzenetére
Szerintem azért vagy bajban, mert nincs olyan, hogy "Az esemény".
Esemény lehet egy mérkőzés, egy átigazolás.
Tehát kell egy olyan tábla, hogy:
- mérkőzések
- átigazolásokMindegyiknek más a struktúrája, de mindegyikből ki lehet nyerni egy dátumot, egy esemény megnevezést, így össze tudsz rakni egy queue-t ami dátum szerint sorba rendezve mutatja a mérkőzéseket és eseményeket.
Ezt a sok csapat és sok személy dolgot meg nem értem vagy te nem érted a relációs adatbázis működését.
Egy mérkőzéshez max. 2 csapat tartozhat, 1 bíró, 1 tartalék bíró és 2 partjelző.
Viszont mivel a játékosok, bírók és partjelzők között bármilyen átfedés lehet, ezért a személyek táblába kellenek flagek, amikkel be lehet állítani, hogy az adott személy melyik halmazoknak a tagja.
Itt már írtam róla bővebben...ezt kell kiegészíteni pár dologgal, elég egyszerűnek néz ki nekem.
Sokkal egyszerűbb lenne az élet, ha feldobnád ide a táblákat, amik már készen vannak, és azok mentén raknád fel a kérdéseket, mert arra lehet gyorsan válaszolni, nincsen időm és kedvem az egészet megtervezni helyetted.
-
kezdosql
tag
Sajnos nem jo, mert alapertelmezesben minden jatekos es edzo a szezon kezdetetol a vegeig adott csapathoz tartozik, es a serulesek csak alkalmankent derulnek ki.
Arra jottem ra, hogy nem a szemelyek vagy a csapatok, hanem az esemenyek a fontosak, innen szemlelve lehet kezelni mindent, hiszen minden merkozes es atigazolas, stb. mind-mind esemeny.
Megis, akarhogy allok hozza a kapcsolatokhoz, mindig elakadok a szemelyek es csapatok kezelesenel.:-(
A buktato az, hogy egy esemenyhez tobb csapat ES sok szemely tartozik.
Egy csapathoz a szemelyek kozul egy vagy tobb edzo ES jatekosok tartoznak.
Az edzok kozul egy aktiv, vagy vezeto edzo, ha tobb van, a tobbi segededzo.
A jatekosok az elso merkozesig kerettagok, akkor derul ki, hogy kezdo, csere, tartalek vagy serult a statuszuk, ha egyik sem, akkor maradnak kerettagnak.Egy szemely egy esemenynel edzo VAGY jatekos VAGY biro/partjelzo lehet. (Kizaro vagy kapcsolat)
Az edzok es jatekosok mindig csapatokhoz tartoznak, a birok-partjelzok mindig fuggetlenek.
Egy szemelynek egy esemenyen csak egy szerepe lehet, de esemenyek soran akar az osszes lehetseges szerepe elofordulhat akar egy szezonon belul. Ezert a kesobbi elemzesnel nem szemelyre, hanem szemelyre ES szerepre kell keresni.
(Vagy a szerepet kell elsodlegesnek valasztani, es azon belul kell keresni a szemelyre ugy, hogy mas szerepe ne legyen a talalatok kozott.)Hihetetlen, hogy ket hete ragom a gittet, es akarhogy allok neki, sehogy se jon ossze a kapcsolati halo, pedig nyilvan itt van a megoldas az orrom elott. :-(
RDS MySQL 5.6-ot frissitunk 5.7-re, es az Amazon szerint az uzemkiesest drasztikusan le lehet csokkenteni ha a kovetkezo alteraciot vegigtolom az adatbazisokon. A gond csak annyi, hogy nekem ez nagyon magas. Ha valaki csinalta mar vagy erti mirol van szo es nem banja kifejthetne nekem 
ehh, ott maradt az id az elején, megzavart az anonimizálva 
Új hozzászólás Aktív témák
- Sorozatok
- MWC 2025: A ThinkPad notebookokról sem feledkezett meg Lenovo
- Tőzsde és gazdaság
- Variálhat az apertúrával az S26 Ultra
- mefistofeles: OTP mobilbank Persely. Jó, de nem jó.....
- Kingdom Come: Deliverance II teszt
- Autós topik
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- Kapcsolja ki, kapcsolja be!
- AMD GPU-k jövője - amit tudni vélünk
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest