- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- gban: Ingyen kellene, de tegnapra
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Geri Bátyó: Megint tahó voltam – SZEMÉLYISÉGFEJLŐDÉS
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Brogyi: CTEK akkumulátor töltő és másolatai
- LordAthis: AI (és másra is használt) Cluster építése - Második Cikk
Új hozzászólás Aktív témák
-
csusza`
senior tag
Igen.
5.1 alól kidumpolt fájlt az 5.6.28-ba gond nélkül beemelte, e fölött verzióknál már gond volt.
5.6.9-re, sem 5.7.11-re nem ment át rendesen, valami hibával elszállt.Próbáltam utána a működő 5.6.28-at bedumpolni újabba, ugyanúgy elszállt. Pedig jó lenne a lehető legfrissebb verziót felrakni, de most egyelőre nem volt kedvem tovább próbálkozni vele.
-
csusza`
senior tag
Szia!
Megpróbáltam, az utolsó parancsnál leakadt a rendszer.
Újraindítottam, azóta a root jelszót is eldobja a rendszer, és be sem enged a MySQL parancssorba sem!
Nem gáz, le vannak mentve az adatbázisok, próbálkozom, csak pár nap alatt tényleg meg kell oldanom a dolgot.@martonx: az elméleti részéhez nem értek, nem is akarok belemerülni, csak legyen áthelyezve nekik az új szerverre ...
-
sonar
addikt
-
martonx
veterán
válasz
csusza`
#1795
üzenetére
Mármint valóban a MySQL-hez van 30 felhasználód, vagy a MySQL-en futó rendszerben van 30 felhasználó? Mert általában magához az SQL-hez nem szokott sok felhasználó lenni. Gondolnám, hogy a MySql Workbench nem teljesen kompatibilis az ősi 5.1-es MySql-lel, és ezért jön ez a hiba.
-
csusza`
senior tag
Sziasztok!
Egy kis segítségre lenne szükségem, mivel nem értek az adatbázisokhoz, de most rákényszerültem, hogy kicsit utána járjak a dolgoknak.
Van egy körülbelül 10 éves Linux szerver, amin fut egy MySQL 5.1 adatbázis. Ezt pár napon belül át kell helyezni egy Windows Serverre.
Az adatbázist elérem MySQL Workbench-el, szépen az automatikus Migration Tool áthelyezgeti a kért adatbázist, látszólag minden rendben lezajlik.
Azonban, amikor a Users/Privileges menüpontba bemegyek, kiválasztok egy felhasználót, hibaüzenettel elszáll.
Gondolom a felhasználók másolásánál van valami gond, próbáltam utána nézni a neten ennek, de érdemi választ nem találtam.
Felvinném én kézzel a felhasználókat, nem lenne azzal gond, de van vagy 30 ember, a fele nem is tudja azt a nyomorult jelszót...
-
#1788
Apollo17hu
őstag
NoX
#1786
Apollo17hu
őstag
Ha az "adatok" mező minden egyes rekordban tartalmazza az 'Iskolai végzettség:', 'Foglalkozás:', 'Anyja neve:' és 'Szem.ig.sz:' karaktersorozatokat, akkor az INSTR() függvénnyel meg tudod keresni, hányadik karakter az 'Anyja neve:' kezdete, hányadik a 'Szem.ig.sz:' kezdete, a kettő közötti karaktersorozatot pedig SUBSTR() függvénnyel ki tudod vágni. Ez lesz az anyja neve (amiből az 'Anyja neve:' karaktersorozat levágása már egy fokkal egyszerűbb).
-
Segítsetek légyszi az alábbi probléma megoldásában.
Van egy emberek adatait tartalmazó adatbázisom, amit korábban nem minden adatra készítettek fel, így pl. az anyja nevét az egyéb adatokba vették fel még rengeteg mással együtt. Ezt szeretném most egységesíteni.
Létrehoztam az "anyja_neve" oszlopot, és ebbe szeretném belemásolni a megfelelő értéket az egyéb adatokból.Az 'adatok' mező tartalma (text type):
Iskolai végzettség: xxx
Foglalkozás: xxx
Anyja neve: xxx yyy
Szem.ig.sz: 000Ebből az anyja nevét kinyerve szeretném áthelyezni az 'anyja_neve' oszlopba. És ha lehet, akkor törölni is ezt a sort ebből az adatok mezőből.
Később persze ezt tervezem a többi adattal is, hogy felszámoljam ezt a mezőt az ömlesztett adatokkal, és külön legyen minden.
Köszönöm.
-
#1785
martonx
veterán
Apollo17hu
#1784
martonx
veterán
válasz
Apollo17hu
#1784
üzenetére
A tökéletes példa arra, hogy miért nem így kellett volna a táblát felépíteni, hanem egy a többhöz kapcsolattal külön táblába tenni a Zone-okat.
-
#1784
Apollo17hu
őstag
laracroft
#1781
Apollo17hu
őstag
válasz
laracroft
#1781
üzenetére
Azon rekordokat keresem, akinek a COMP táblájának ZONE1-ZONE16 mezőjeiben szerepel a PROC szó ÉS a 16 zónából 5-nél kevesebb mezőben van egyáltalán valamilyen érték (Nem csak PROC szó szerepelhet a mezőkben)
...
WHERE COMP.ZONE1 || "." ||
COMP.ZONE2 || "." ||
COMP.ZONE3 || "." ||
COMP.ZONE4 || "." ||
COMP.ZONE5 || "." ||
COMP.ZONE6 || "." ||
COMP.ZONE7 || "." ||
COMP.ZONE8 || "." ||
COMP.ZONE9 || "." ||
COMP.ZONE10 || "." ||
COMP.ZONE11 || "." ||
COMP.ZONE12 || "." ||
COMP.ZONE13 || "." ||
COMP.ZONE14 || "." ||
COMP.ZONE15 || "." ||
COMP.ZONE16 LIKE "%PROC%" AND
CASE WHEN COMP.ZONE1 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE2 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE3 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE4 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE5 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE6 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE7 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE8 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE9 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE10 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE11 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE12 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE13 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE14 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE15 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE16 IS NOT NULL THEN 1 ELSE 0 END < 5 -
martonx
veterán
válasz
laracroft
#1781
üzenetére
Tudom csak kívülről beleokoskodás valós megoldás helyett, de milyen hülyeség már, hogy Zone1-16 mezők vannak a táblában, miközben sokkal normálisabb megoldás lenne, ha egy a többhöz kapcsolatban a Zone-ok ki lennének szervezve egy külön táblába. És máris elég lenne egy group by rájuk az ilyen lekérdezésekhez
Ha pedig valahol mégis egymás mellett kellene megjeleníteni őket, akkor mehetne egy view a táblára benne egy pivot-tal. Sokkal normálisabb adatbázis szerkezet lenne.
-
#1781
laracroft
senior tag
Apollo17hu
#1777
laracroft
senior tag
válasz
Apollo17hu
#1777
üzenetére
Szia!
Kipróbáltam a kódot, de sajnos nem tűnik jónak
Olyan rekordokat is kiad, amelyeknek több mint 5 zónájuk is ki van töltve.
Közben rájöttem, hogy nem voltam teljesen korrekt a feladat leírásában sem, bocsánat.Azon rekordokat keresem, akinek a COMP táblájának ZONE1-ZONE16 mezőjeiben szerepel a PROC szó ÉS a 16 zónából 5-nél kevesebb mezőben van egyáltalán valamilyen érték (Nem csak PROC szó szerepelhet a mezőkben)
Így nézett ki most a lekérdezés: (Így gondoltad?)
SELECT
UGYFEL.LINE AS VONAL,
UGYFEL.COMPSZAM AS COMPSZAM,
UGYFEL.NAME1 AS NEV,
UGYFEL.ADDRESS3 AS IRSZAM,
UGYFEL.ADDRESS1 AS VAROS,
UGYFEL.ADDRESS2 AS UTCA
from UGYFEL
LEFT JOIN COMP
ON UGYFEL.LINE = COMP.LINE
where
CASE WHEN COMP.ZONE1 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE2 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE3 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE4 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE5 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE6 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE7 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE8 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE9 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE10 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE11 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE12 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE13 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE14 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE15 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE16 LIKE "%PROC%" THEN 1 ELSE 0 END < 5)
order by VONAL -
#1780
laracroft
senior tag
Apollo17hu
#1777
laracroft
senior tag
válasz
Apollo17hu
#1777
üzenetére
Köszi kipróbálom
-
#1779
laracroft
senior tag
Peter Kiss
#1778
laracroft
senior tag
válasz
Peter Kiss
#1778
üzenetére
~15000
-
#1777
Apollo17hu
őstag
laracroft
#1776
Apollo17hu
őstag
válasz
laracroft
#1776
üzenetére
Nem tudom, hogy mysql-ben van-e CASE WHEN, de ha igen, akkor:
WHERE
...
CASE WHEN COMP.ZONE1 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE2 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE3 LIKE "%PROC%" THEN 1 ELSE 0 END +
...
CASE WHEN COMP.ZONE16 LIKE "%PROC%" THEN 1 ELSE 0 END < 5...tehát képzel egy 16 tagú összeget, és megnézed, hogy kisebb-e 5-nél.
-
laracroft
senior tag
Sziasztok!
Van egy COMP táblám, amiben van 16 db ZONE mező.
Ezek némelyike ki van töltve, némelyike nincs. Van hogy csak pl. a 2,5,6,8,10-es ZONE van kitöltve, van hogy mindegyik, van hogy egyik sem.
Keresem azon ügyfeleket, akiknek zónalistájában szerepel a "PROC" szó és a kitöltött zónák száma kevesebb 5-nél.
Na ez a kitöltött zónák száma kevesebb 5-nél kifogott rajtam.
Tudnátok segíteni?Előre is köszi!
SELECT
UGYFEL.LINE AS VONAL,
UGYFEL.COMPSZAM AS COMPSZAM,
UGYFEL.NAME1 AS NEV,
UGYFEL.ADDRESS3 AS IRSZAM,
UGYFEL.ADDRESS1 AS VAROS,
UGYFEL.ADDRESS2 AS UTCA
from UGYFEL
LEFT JOIN COMP
ON UGYFEL.LINE = COMP.LINE
where
(COMP.ZONE1 LIKE "%PROC%"
or COMP.ZONE2 LIKE "%PROC%"
or COMP.ZONE3 LIKE "%PROC%"
or COMP.ZONE4 LIKE "%PROC%"
or COMP.ZONE5 LIKE "%PROC%"
or COMP.ZONE6 LIKE "%PROC%"
or COMP.ZONE7 LIKE "%PROC%"
or COMP.ZONE8 LIKE "%PROC%"
or COMP.ZONE9 LIKE "%PROC%"
or COMP.ZONE10 LIKE "%PROC%"
or COMP.ZONE11 LIKE "%PROC%"
or COMP.ZONE12 LIKE "%PROC%"
or COMP.ZONE13 LIKE "%PROC%"
or COMP.ZONE14 LIKE "%PROC%"
or COMP.ZONE15 LIKE "%PROC%"
or COMP.ZONE16 LIKE "%PROC%")
order by VONAL -
amdni
aktív tag
Sziasztok.
Most tanulok mysql workmench programban létrehozni adatbázist, sajnos itthon nem működik úgy mint iskolában. Feltelepítettem a programot, létrehoztam a tömböt de nem engedi a program hogy beleírjak.
Link:
http://kepfeltoltes.hu/view/151206/MySQL_Workbench_www.kepfeltoltes.hu_.jpg
-
theo_76
aktív tag
kicseréltem azokat a feltételeket, bár nem értem miért nem jó, mivel pont az lenne a lényeg (és végül is működött is a feltétel), hogy azokat a sorokat válogassa ki, amik még nem kaptak semmilyen értéket. Viszont az igazi problémán nem változtat, az ORDER BY, így se teljesül...
-
theo_76
aktív tag
Azt is próbáltam már... Az a vicces, hogy ha a szűrőt kiveszem, akkor tökéletesen rendez. Mintha a WHERE utasítás semlegesítené az ORDER BY-t... Próbáltam még a phpmysql-en keresztül lefuttatni a parancsot, de ott meg null sorral tér vissza sajnos más lehetőségem meg nincs, hogy programmal (pl az MySQL Workbench) beletudjak nézni az sql működésébe... a php kód a 000webhost.com ingyenes tárhelyen fut. Sajnos otthoni körülmények között frissebb mysql-el php-vel nincs most alkalmam kipróbálni.
-
-
sonar
addikt
válasz
theo_76
#1764
üzenetére
Még vmi, a NULL keresés akkor működik rendesen ha vmilyen INT típusú a mező.
Egyébként, tényleg jónak kellene lennie. Próbáld meg azt, hogy a select-ben egymás után rakd be az order by-ban felsorolt mezőket. Aztán akkor látszik, hogy mi lehet még az elcsúszás oka.
SELECT
szabadsag.*,user_data.munk_telep, user_data.munk_csop, user_data.name, user_data.email,
user_data.szabadsag_eves, user_data.szabadsag_kivett -
theo_76
aktív tag
már az első karaktereknél elcsúszik, amik nem tartalmaznak ékezetes karaktereket. Egyébként a tábla karakterkészlete utf8_hungarian_ci, és a php-ben is úgy állítottam be az sql lekérdezéseket. Ha a WHERE-el nem szűröm meg a lekérdezést, akkor tökéletesen rendez, de ha beteszem a szűrőt, hogy csak bizonyos adatok jelenjenek meg, akkor olyan mintha az ORDER BY utasítás nem is létezne. Ha kiveszem, akkor is ugyan abban a sorrendben jelennek meg, amilyen sorrendben rögzítettem a sorokat. Pl most így néz ki WHERE utasítással ORDER BY-al, és nélküle is:
Komló...
Komló...
Kozármisleny...
Komló...
Komló...WHERE nélkül, ORDER BY paranccsal:
Komló...
Komló...
Komló...
Komló...
Kozármisleny... -
theo_76
aktív tag
Sziasztok!
Van egy sql kérésem:
SELECT
szabadsag.*, user_data.name, user_data.email, user_data.munk_telep, user_data.munk_csop,
user_data.szabadsag_eves, user_data.szabadsag_kivett
FROM
szabadsag
INNER JOIN
user_data
ON
szabadsag.ID=user_data.ID
WHERE
szabadsag.checkEngedely IS NULL OR szabadsag.checkJovahagy IS NULL
ORDER BY
user_data.munk_telep, user_data.munk_csop, user_data.name ASCa gond az vele, hogy az ORDER BY parancs nem akar teljesülni, ha viszont a WHERE-t kiveszem, akkor rögtön működik...
A szerver adatai, ahol a kód fut: Apache 2.2.19; PHP 5.2; MySQL 5.1
-
#1758
martonx
veterán
fordfairlane
#1756
martonx
veterán
válasz
fordfairlane
#1756
üzenetére
Ja, hogy arra? Na, azt még soha nem használtam.
-
-
Gyb001
senior tag
Üdv.
A beadandómhoz kérnék egy kis segítséget.Hogyan tudok sql ben többértékű és összetett tulajdonságot létrehozni?
ER diagramon és relációs modellben egyértelmű a dolog, de sql ben nem tudom hogy kellene megvalósítani.Péda:
Többértékű:
Egy alkalmazottnak lehet több végzettsége is ezeket el kell tárolni.Összetett:
A lakcím több részre bontható. Irszám, utca, házszám ...
-
MineFox54
őstag
Sziasztok!
Át kellett vinnem egyik (döglött) gépről a másikra a mysql fájlokat, viszont ezt csak fájlrendszeri szinten tudtam megtenni (kimásolom, új gépen bemásolom). Két DB-nél működik is ez, viszont a harmadiknál nem látja az amúgy ottlévő frm fájlokat. Mit kéne tennem?
-
qfm
őstag
Igazából a leírtak 90%-a nem valódi honlap lesz, hanem eszközök közötti kommunikációra szolgál. Emberek által látott felület minimális lesz. A rekordok száma esetén a maximálisat írtam le, amit a kiépítés megkívánhat. Pentium alatt egy modern G3220-ra gondoltam, nem egy P4-re, de valóban nem definiáltam. Ennek ellenére i3 alatti gépet nem fogok javasolni, csak érdekel mennyire lövök túl a célon. A dedikált hardver külön elvárás volt.
(#1746) martonx
1, A 4gb-os ram nem kifejezetten drága, így csak megnyugtat a tudat, hogy szerinted is bőségesen elég.
2, A forgalom csak akkor ugorhat meg, ha valamelyik hardver meghibásodik, eléggé jól leszűrt forgalom van rá tervezve.
3, A dedikált szerver külön kérés volt, én is mást ajánlottam, de bizonyos okok miatt ez volt a kérés.
4, Soha nem használtam még NoSQL-t, de utána fogok nézni a javaslatodnak.
5, A számok azért ilyen alacsonyak, és talán furák is, mert egy speciális hardver kommunikációhoz lesz csak háttér adatbázis. Az adatmennyiség limitált amit tárolni, és feldolgozni kell.
6, Valóban nagyon egyszerű, és a kimenet előállításához nem is szükséges több sql művelet. A bemenet függvényében azonban több különböző folyamat zajlik le, van amelyik 1 hívással jár, van amelyik 3-al. A legrosszabb esetet vettem alapul. A kimenet pusztán nyugtázó funkciót lát el.+1 a 6-osból adódna a kérdés, hogy miért nem az adatbázist használják a hardverek, hanem a köztes PHP oldalt. Azért mert ez volt az igény.
-
sonar
addikt
Én is osztom martonx véleményét, de minden project így indul, hogy csak pár rekord...
Manapság a HW ára és egy migrálással / költöztetéssel eltöltött idő ára nincs arányban.
Nem tudom milyen volumenü a project, de P4 -es pentiumot alapból vágnám ki a kukába ha komoly dologról van szó. 10 éves géppel ne szórakozzunk már... -
martonx
veterán
Szia!
Előre bocsátom, hogy semmi háttérinfóm nincs, így lehet, hogy az alábbiak csak okoskodásnak fognak hatni. Észrevételeim:
1. Ehhez a feladathoz ha jól tippelem ramból kb. semennyi nem kell, a 4Gb abszolút feleslegesen felülméretezettnek tűnik egy pár tíz Mbyte-os adatbázishoz. Cakkumpakk be fog férni a komplett adatbázis a memóriába.
2. CPU-ból egy négy magos vígan ki kellene, hogy tudja szolgálni mindezt. A Pentium necces lehet, és mi van például, ha megduplázódik a terhelés? Akár csak percekre?
3. Pont a fentiek miatt, ma már senki nem gondolkozik saját vas beszerzésében, hanem sokkal érdemesebb szervert bérelni valahol, leginkább mondjuk a felhőben. Így kb. egy csúszka arrébb tolásával meg tudod többszörözni az erőforrásokat, ha épp arra van szükség.
4. Nem vagyok egy nagy NoSQL rajongó, de ez tipikusan olyanfeladatnak tűnik, ahol teljesen felesleges tranzakciós SQL-t használni, egy NoSql sokkal kevesebb erőforrás használatával, sokkal nagyobb teljesítményt tudna elérni.
5. Másrészt megfontolandó, hogy tényleg jól van felépítve az adatbázisotok? Lehet, hogy nem a NoSQL a megoldás, csak alapból szar az SQL-etek architektúrája?
6. Nekem gyanús a backendetek is. Ahogy írod elég faéknek tűnik, mégis miért van szükség egy minimális adat kimenethez több SQL query-re? Lehet érdemes lenne tárolt eljárást írnotok, sql view-t használnotok, php oldalon optimalizálni a kódon, cache-elést bevezetni stb... -
qfm
őstag
Sziasztok!
Lehet nem jó helyen próbálkozok ezzel, de hátha van közöttetek olyan aki tud rá válaszolni. A mai modern cpu-k közül, minimálisan milyen lenne szükséges ahhoz, hogy egy LAMP szerver másodpercenként 400 selectet, és 100 updatet kiszolgáljon? A selectek nem tartalmaznak joint, és bonyolult műveleteket. A tábla amin updatelni kell, és a selectek fele fut, pusztán 500 rekordot fog tartalmazni, a selectek másik fele, egy nagyjából 2000 rekordot tartalmazó táblán fog futni. Érzésem szerint ezek nem magas elvárások, és akár egy 2 magos pentium is elbírná 4gb rammal, de inkább rákérdeznék nálatok.
A webserver nem lesz leterhelve, másodpercenként maximum 250 hívást kaphat, ami egy viszonylag rövid script segítségével 1 karakteres outputot állít elő (az sql műveletek mellett, amit fentebb írtam). -
sonar
addikt
-
MineFox54
őstag
Sziasztok!
Ezzel mi baja van?
UPDATE reg SET `tav'='$tav', 'gender'='$gender', 'birthday'='$birthday', 'name'='$name', 'email'='$email', 'varos'='$varos', 'utca'='$utca', 'focinev'='$focinev', 'telefonszam'='$telefon', 'szamla'='$szamla', 'egyesulet'='$egyesulet' WHERE email='$email'ezt php-ben feltöltöm adatokkal:
Error: UPDATE reg SET `tav'='kerekpar21', 'gender'='ferfi', 'birthday'='xxxxxxxx', 'name'='Somogyi Soma', 'email'='sskss73@gmail.com', 'varos'='xxxxxxx', 'utca'='xxxxxxxxxx', 'focinev'='-', 'telefonszam'='xxxxxxx', 'szamla'='-', 'egyesulet'='-' WHERE email='xxxxxxxxx'
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 '' at line 1 -
sonar
addikt
A lenti query-vel van egy olyan problémám, hogy ha ez a két feltétel benne van a select-ben
e.port_speed !='null' and e.port_speed != 'N/A'
akkor az insert elszáll az alábbi hibakóddal
Error Code: 1292. Truncated incorrect DOUBLE value: 'null'Nem értem, hogy mi a baja, pont azért akarom kiszűrni a null-t és az N/A-t, hogy hülyeség ne kerüljön be az adatbázisba.
insert into tbl_port_summary (port_id,summa,speed_1000M,speed_100M,speed_10M)
SELECT e.port_id, count(*) as Ossz, sum(if (e.port_speed='1000',1,0)) as Speed_1000M,
sum(if (e.port_speed='100',1,0)) as Speed_100M,sum(if (e.port_speed='10',1,0)) as Speed_10M
FROM tbl_log_011 as e
where e.port_speed !='null' and e.port_speed != 'N/A'
and e.timestamp > 1434326400
group by e.port_id order by e.port_id,e.timestamp; -
don_peter
senior tag
User mindig létezik, ha már készült bejegyzése, más módon inaktiválódik..
Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)
Erre egy példát tudnál készíteni nekem?
A topikok összességét nem limitálom, de gondolom, ha eljön az ideje azt is meg fogom oldani, bár még egyelőre nincs elképzelésem hogyan..
Itt tudod megnézni miről is van szó: [link]A fórum bejegyzések limitálva vannak termesztésen, maximum 20db van 1 lapon...
-
bpx
őstag
válasz
don_peter
#1731
üzenetére
Feltételeztem, hogy olyan eset nem fordul elő, hogy egy fórum üzenethez nem létezik user (mert usert általában nem törlünk, csak inaktiválunk), és így nem kell ezek közé is outer join, de egyébként igen.
Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)
MySQL-ben sajnos nincsenek analitikus függvények, helyette vannak ilyen kerülő megoldások:
Végül limitálni kellene, hogy hány sort kapunk vissza, hogy ne dolgozzon esetleg feleslegesen az adatbázis, és gondolom a felhasználónak sem a létező összes, akár több száz, ezer topikot rakod ki felületre, hanem csak egy fix mennyiséget, ahogy pl. itt a prohardveren is működik.
-
don_peter
senior tag
A fenében
Totálisan igazad van, kezdek megvakulni..
Gondolom most már az lehet a baj, hogy egy hete folyamatában megállás nélkül írom az új kódokat és már kezdek belefáradni.A leegyszerűsített kód ami működik:
SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM topik t
LEFT JOIN forum_uzenetek fu
ON fu.topik_id = t.id
LEFT JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESCGondolom erre gondoltál te is...
-
bpx
őstag
válasz
don_peter
#1729
üzenetére
Ha azok a topikok kellenek, amelyekben nincs hozzászólás, akkor miért a forum_uzenetek van a LEFT JOIN bal oldalán?
forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.idEz azt jelenti, hogy azokat fórum üzeneteket is kéred, amelyek egyik topikhoz sem tartoznak.
forum_uzenetek LEFT JOIN topik + UNION bonyolítás helyett nem egyszerűbb lenne a topik LEFT JOIN forum_uzenetek?
-
don_peter
senior tag
válasz
don_peter
#1728
üzenetére
No ez már jó
Hátha tudok vele segíteni...
Aki tud ennél egyszerűbb megoldást az kérem ossza meg velem.
Köszönöm.SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick
FROM topik t
where t.topik_csoport_id = 9
) c
GROUP BY id ORDER BY datum DESC -
don_peter
senior tag
válasz
don_peter
#1727
üzenetére
Nos kicsi átalakítással már működik is és elég gyors 0.1mp-es lefutási időt produkál.
SELECT * FROM
(SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) as a
GROUP BY a.id
UNION
SELECT t.id, t.title, "1970-01-01" as datum, NULL as nick FROM topik t where t.topik_csoport_id = 9) c
GROUP BY id ORDER BY datum DESCKöszi a segítséget és az elvi rávezetést...
ui: öhh, még sem jó..
Nem jól szelektálja az utolsó bejegyzéseket.
Ennek még utána nézek.. -
#1727
don_peter
senior tag
Apollo17hu
#1726
don_peter
senior tag
válasz
Apollo17hu
#1726
üzenetére
Ez sajnos nem fut le, de értem a gondolat meneted..
Próbálkozom, hátha tudom javítani a kódot. -
#1726
Apollo17hu
őstag
don_peter
#1725
Apollo17hu
őstag
válasz
don_peter
#1725
üzenetére
Az előbb lehet, hogy részben hülyeséget írtam, de valahogy így gondoltam:
SELECT c.* FROM
((SELECT a.id, a.title, a.datum, a.nick FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) AS a
GROUP BY a.id) b
UNION
(SELECT t.id, t.title, 1000-01-01 as datum, NULL as nick FROM topik t) seged) c
GROUP BY c.id
ORDER BY c.datum DESC...tehát minden topikhoz létrehozol egy 1000-01-01 dátumra vonatkozó hsz.-t, ami csak akkor számít a sorrendben, ha nincs rajta kívül más hsz. (tehát ha üres a fórumtéma).
-
#1725
don_peter
senior tag
Apollo17hu
#1724
don_peter
senior tag
válasz
Apollo17hu
#1724
üzenetére
Van UNION..
Utána nézek...
Ha van egy megoldásod, akkor az is jöhet..
Köszi.. -
#1724
Apollo17hu
őstag
Apollo17hu
őstag
Ha van UNION utasítás MySQL-ben, akkor megoldás lehet, hogy összefűzöd egy olyan lekérdezéssel, amiben minden topik szerepel, de mondjuk 999999-es id-val (amit konstansként adsz meg).
Vagy átírod az egészet úgy, hogy a topikhoz kötöd gyengén a dolgokat, nem pedig azt kötöd gyengén a hsz.-ekhez.
-
don_peter
senior tag
Srácok van egy ilyen lekérdezésem:
SELECT * FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESCA kód hibája az, hogy ha nincs bejegyzés egy meglévő topikban, akkor azt nem listázza ki.
Tudom, hogy itt a hozzászólásokhoz van csatolva a dolog, de miképpen tudom ezt úgy megoldani, hogy azt a topikot is listázza amelyikben még nincs bejegyzés?
Természetesen azt a végére kell kilistáznia.Erre a részre, ha beteszek egy ilyet:
ON t.id = fu.topik_id or t.id
Akkor listázza, de az első helyen és belassítja kb. 10szeresen a lefutási időt.
Ráadásul nem is jó így...Előre is köszönöm.
-
#1722
fordfairlane
veterán
TomyLeeBoy
#1721
fordfairlane
veterán
válasz
TomyLeeBoy
#1721
üzenetére
A / max regexp patterdefinícióknál okozhat gondot, sehol máshol. Elég elcseszett sztringkezelés lehetett abban a scriptben.
-
#1721
TomyLeeBoy
tag
biker
#1720
TomyLeeBoy
tag
-
#1719
sonar
addikt
TomyLeeBoy
#1718
sonar
addikt
válasz
TomyLeeBoy
#1718
üzenetére
Szerintem a php-vel van a baj, mert escape karakternek érzékeli.
Nézz utána a stripslashes() függvénynek. -
#1718
TomyLeeBoy
tag
TomyLeeBoy
tag
Üdv mindenki!
Egy mysql lekérésem nem futott le végig, úgy éreztem kimaradnak elemek, így elkezdtem utána járni a dolognak és a következő lett a megoldás:
Az egyik rekord VARCHAR típusú, 50 hosszú mezőjében a következő érték van: M01535/2015/004723
Ennél a rekordnál meghal a lekérdezés. Ha bármi mást írok a helyére akkor szépen lefut. Nem értem mi ebben a speciális tartalom hogy ez miatt nem megy. Másik rekordnak ugyanebben az elemében is vannak / jelek és azzal semmi gond.
Ha tudnám hogy mi a baja ezzel, csinálnék valami védelmet hogy ne lehessen olyat beírni amitől nem fog működni a lekérdezés, de nem tudok rájönni ezzel mi a gond.A lekérdezés:
SELECT * FROM tabla WHERE YEAR(date) = '2015' AND MONTH(date) = '5' AND sum='1' ORDER BY date DESCés php-ban while-al járom végig.
Ha valakinek van ötlete nagyon megköszönném.
-
#1716
don_peter
senior tag
Apollo17hu
#1715
don_peter
senior tag
válasz
Apollo17hu
#1715
üzenetére
Bár a lekérdezésed lefut és majdnem jó is csak valamiért szelektál.
Nem az összes bejegyzést figyeli.Most ezt írtam és használom ez jól működik, legalább is úgy tűnik:
SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESC LIMIT 8 -
#1715
Apollo17hu
őstag
don_peter
#1714
Apollo17hu
őstag
válasz
don_peter
#1714
üzenetére
Akkor két allekérdezés kell:
- az egyikben listázod topikonként a legfrissebb hsz.-ek dátumát,
- a másikban pedig leszeded topikonként a userek legfrissebb hsz.-eit.Ezt a kettőt topik-topik és dátum-dátum kötéssel kötve ezt kapod:
SELECT topik_datum.title,
topik_user_datum.nev,
topik_datum.updatum
FROM (SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.title) AS topik_datum,
(SELECT t.id AS tid,
u.nick AS nev,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id
GROUP BY t.id,
u.id) AS topik_user_datum
WHERE topik_datum.tid = topik_user_datum.tid
AND topik_datum.updatum = topik_user_datum.updatum
ORDER BY topik_datum.updatum DESC LIMIT 8Hogy milyen gyorsan fut le, az jó kérdés, de analitikus függvények nélkül ennél jobbat nem tudok.
-
#1714
don_peter
senior tag
Apollo17hu
#1712
don_peter
senior tag
válasz
Apollo17hu
#1712
üzenetére
Igen az nem jó, ezt én is tudom ezen tovább is léptem már.
Most már az egész lekérdezést nézem nem csak részleteket.
Sok a subselect és ez megnehezíti a lekérdezést. -
#1713
don_peter
senior tag
Apollo17hu
#1712
don_peter
senior tag
válasz
Apollo17hu
#1712
üzenetére
Makszimum 8 topik jelenik meg az utolsó bejegyzések alapján csökkenő sorban.
-
#1711
Apollo17hu
őstag
don_peter
#1709
Apollo17hu
őstag
-
#1710
fordfairlane
veterán
Apollo17hu
#1707
fordfairlane
veterán
válasz
Apollo17hu
#1707
üzenetére
MySQL tud analitikus függvényeket?
Tudomásom szerint egyiket sem ismeri.
-
#1709
don_peter
senior tag
Apollo17hu
#1707
don_peter
senior tag
válasz
Apollo17hu
#1707
üzenetére
Ezt a nyelvet már nem ismeri.
Legalább is ebben a formában.
Köszi azért, el voltam vele kicsit -
#1708
don_peter
senior tag
Apollo17hu
#1707
don_peter
senior tag
válasz
Apollo17hu
#1707
üzenetére
A limit 8 azt jelenti, hogy csak 8 record-ot kérjen le. Esetünkben a 8 legfrissebbet.
-
#1707
Apollo17hu
őstag
don_peter
#1706
Apollo17hu
őstag
válasz
don_peter
#1706
üzenetére
MySQL tud analitikus függvényeket? Ha igen, akkor én valahogy így csinálnám:
SELECT x.*
FROM (SELECT t.id AS tid,
t.title AS title,
fu.datum AS updatum,
u.nick AS nev
rank() OVER (PARTITION BY t.id ORDER BY fu.datum DESC) AS sorrend
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id) AS x
WHERE x.sorrend = 1Amúgy az a nyolcas limit mi akar lenni a lekérdezéseidben?
-
don_peter
senior tag
válasz
don_peter
#1705
üzenetére
Gondolok itt ilyesmire:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum,
u.nick AS nev
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id AND u.id = fu.user_id
GROUP BY t.id,
t.title
u.id
ORDER BY `updatum` DESC LIMIT 8Vagy ezt tovább már nem lehet feszegetni?
-
#1705
don_peter
senior tag
Apollo17hu
#1704
don_peter
senior tag
válasz
Apollo17hu
#1704
üzenetére
Köszönöm, ez így 3.8-4mp-ről 0.18-0.22mp-re csökkentette a lekérdezési időt.
A csoportosítást lehet még tovább bonyolítani?
Ha mondjuk még kíváncsi lennék a bejegyzést készítő felhasználó nevére? -
#1704
Apollo17hu
őstag
don_peter
#1698
Apollo17hu
őstag
válasz
don_peter
#1698
üzenetére
Ha topikonként a legfrissebb bejegyzésre van szükséged, akkor valahogy így kellene:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.titleEz mondjuk nem MySQL, de a kétszeri sorbarendezést (ORDER BY) kiváltja egy aggregáló függvény, ami valószínűleg gyorsít rajta.
Új hozzászólás Aktív témák
Hirdetés
- Egérpad topik
- Nothing Phone (3) – tervezett kaotika
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- 5G-s szettel frissült az Infinix belépő modellje
- Automata kávégépek
- GL.iNet Flint 2 (GL-MT6000) router
- Borderlands
- Először égett le egy újságnál a GeForce RTX 5090
- Milyen belső merevlemezt vegyek?
- Tenisz topic
- További aktív témák...
- HP 14 Elitebook 640 G9 FHD IPS i5-1235U 4.4Ghz 10mag 16GB 256GB Intel Iris XE Win11 Pro Garancia
- HP 14 Pavilion FHD IPS i5-1135G7 4.2Ghz 16GB RAM 512GB SSD Intel Iris XE Graphics Win11 Garancia
- Aoc 1080p 75hz 27" GRÁTISZ ALZAERGO MONITORKAR!
- HP 15 Pavilion FHD LED Matt Ryzen5 5500U 4.0Ghz 8GB RAM 256GB SSD Radeon RX Vega7 Win11 Garancia
- Gamer Intel Core i5 12400 / 16GB DDR4 / GTX 1660 SUPER 6GB / 256GB NVME SSD / 1TB HDD /
- Azonnali készpénzes Sony Playstation 4 Slim / PS4 Pro felvásárlás személyesen/csomagküldéssel
- DELL PowerEdge R730xd 26SFF rack szerver - 2xE5-2680v3 (24c/48t, 2.5/3.3GHz), 64GB RAM, 10G, H730p
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2048, 96% Akksi
- Samsung Galaxy S20+ 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC-Számítógép! Csere-Beszámítás! I7 6700 / GTX 1660Ti / 16GB DDR4 / 500GB SSD
Állásajánlatok
Cég: FOTC
Város: Budapest