Töröm a fejem rajta, de kicsit homályos, amit írtál. Pontosan milyen eredményt szeretnél? (Olyan példa jó lenne, amilyet az előző kérdésedben írtál.) A "line" mező biztosan az ügyfelet azonosítja? Arra elég az "account", nem? A "line" gondolom, valamilyen rekordazonosító/bejegyzésazonosító, tehát erre nincs szükséged a lekérdezés eredményében. (Vagy igen?)

Egy ügyfélhez bármennyiszer tartozhat a 'Helyszínen' és 'Lellenőrizve' kifejezéseket tartalmazó bejegyzés vagy csak 1-1 (= 2) db? Tehát ügyfelenként csak 0, 1 és 2 érték várható?

Írtam egyet, talán használni tudod, bár én nem MySQL-t, hanem SQL-t használok:

SELECT sub2.account
,sub2.line
,CASE WHEN sub2.ido_helyszinen IS NOT NULL
AND sub2.ido_leellenorizve IS NOT NULL
AND sub2.diff_fl IS NOT NULL
THEN 2 -- ha helyszínen és leellenőrizve is van 15+ perc különbséggel
WHEN sub2.ido_helyszinen IS NULL
AND sub2.ido_leellenorizve IS NULL
THEN 0 -- ha helyszínen és leellenőrizve sincs
ELSE 1 -- minden más esetben
END db
FROM (SELECT sub1.account
,sub1.line
,sub1.ido_helyszinen
,sub1.ido_leellenorizve
,CASE WHEN (sub1.ido_helyszinen - sub1.ido_leellenorizve)*1440 > 15
THEN 'x'
END diff_fl
FROM (SELECT t.account
,t.line
,MIN(CASE WHEN t.leiras LIKE '%Helyszínen%'
THEN t.ido
END) ido_helyszinen
,MIN(CASE WHEN t.leiras LIKE '%Leellenõrizve%'
THEN t.ido
END) ido_leellenorizve
FROM naplo t
WHERE 1=1
AND (t.leiras LIKE '%Helyszínen%' OR t.leiras LIKE '%Leellenõrizve%')
GROUP BY t.account
,t.line) sub1) sub2

[ Szerkesztve ]

Ötlet látatlanban:

1. csinálsz egy alselectet:
select account, line, leiras, min(ido) as minido, max(ido) as maxido
from naplo
where LEIRAS like '%Helyszínen%' or LEIRAS like '%Leellenõrizve%'
group by account, line

2. majd ezt az alselectet felhasználva
select account, line case when timestampdiff(minute, maxido, minido) > 15 then 2 else 1 end as eredmeny
from fenti_alselect

Én kérek elnézést!

Mi az, hogy Java-alapú szerverhez? Az kit érdekel, milyen webszerver fut rajta? Az a lényeg, hogy UNIX/Linux-alapú, vagy Windows. Ettől függ, milyen program ajánlható.

Sk8erPeter

Jó kulcsszavakat beírva elég gyorsan lehet találni válaszokat, például:

JSPMyAdmin

Nem tudom, milyen, nem próbáltam még.

A másikra majd a többiek.

Sk8erPeter

Mire gondolsz skálázhatóság alatt?

Most a terhelhetőség nő lineárisan vagy a terhelés? El lehet szurni, mindent el lehet. Nyilván pár száz oldal letöltésnél per nap nem fog senkinek feltünni hogy egy szar az adatbázisod mert megoldja erőből a géped.

Amit tudsz optimalizálni, hogy 1. Az oszlopokat a bennük tárolt adatra alakitod a lehető legjobban 2. Olyan query-ket írsz amik lehetőség szerint indexek mentén tudnak haladni.

De ha nagy terhelésű rendszert tervezel és fontos a rendelkezésre állás akkor érdemes átnézni a nem relációs adatbázisokból egy-kettőt . Bizonyos feladatokra nagyon jók, de elég sok még gyerekcipőben jár . Vannak hatalmas előnyeik a relációs adatbázisokkal szemben (meg hatalmas hátrányaik is nyilván) . De pl egy cassandrával elég jól tudsz egy clusteren belül terhelés elosztani és az adatbiztonságod is lehet jó egyszerre.

Na, még egy dolog tűnt fel, ami hiányzik a MySQL Workbench-ből (nagyon), a phpMyAdminban viszont ötezer éve megvan: az összes vagy megadott nevű adattáblákban való keresgélés egy adatbázison belül.
phpMyAdminban ezek a kategóriák vannak:
- at least one of the words
- all words
- the exact phrase
- as regular expression
aztán meg lehet adni Ctrl-os kijelöléssel, hogy konkrétan melyik táblákban keressen, vagy ki lehet jelölni az összeset, meg lehet jelölni, melyik nevű mezőben keressen, lehet wildcarddal keresni.

Szóval egyértelmű, hogy a MySQL Workbench egy ostoba szar a phpMyAdminhoz képest.

Sk8erPeter

ööö lehet én vagyok kocka, de ezekere a keresésekre vannak beépített SQL táblák, amik megmutatják a DB szerkezetét. Erre való az information_schema.

Én kérek elnézést!

Ezt most nem egészen értettem. Ki kíváncsi itt a DB szerkezetére?
Konkretizálva például arra vagyok kíváncsi, hogy adott adatbázison belül mely adattáblák mely mezői tartalmazzák azt a stringet, hogy "árvíztűrő tükörfúrógép" (csak hogy egy elvetemült példát mondjak). Hogy nyered ki ezt az information_schema-ból?
De ha meg is tudod ezt tenni, itt arról volt szó, hogy GUI-n keresztül (!!) hogyan lehet kényelmesen kezelni az adattábláidat, anélkül, hogy egyetlen sort le kéne írnod SQL-ben.

Sk8erPeter

bocs, félreértettelek. Fel se merült bennem, hogy valaki ilyet akarna tenni, hogy egy DB összes táblájában keresni akar valamit. Miért teszel ilyet? Ha van jópár több millió soros DB-d, akkor azok mennyire szeretik vajon ezeket a fajta kereséseket? És miért jó az, ha két óra múlva kapsz mondjuk egy választ, de cserébe megölted a komplett SQL szervert az ártatlan kereséseddel?
Az, hogy egy GUI ilyen kényelmi funkciót biztosít, szvsz inkább hátrány, mint előny.

Én kérek elnézést!

- nyilván nagyon nagy méretű, komoly, sok-sokmillió rekordot tartalmazó adatbázisnál nem kezdenék el keresgélni egy stringet; az már vélhetően egy bejáratott, működő rendszer.
- ilyesmit nem illik művelni éles szerveren amúgy sem.
- szvsz nem biztos, hogy meg kell, hogy ölje az egész SQL-szervert a keresés, ha az ehhez tartozó alkalmazás normálisan van megírva: nem kell az összes adattáblát lockolnia addig, amíg végez. Elvileg egyetlen adatbázisban keresek, és a táblákon ciklikusan végig lehet menni, tehát egy lépésben csak egyetlen táblában keresek, string alapon, végignézve az összes szóba jöhető mezőt, kivéve ebből azokat, amiknek köze nincs a string típusú mezőkhöz (tehát elő sem fordulhat például az INT, DATETIME, stb. típusúak közt) - persze abban teljesen igazad van, hogy a string alapú keresés jó qrva lassú, és akkor is végig kell nézni a táblákat, és erőforrás-igényes az egész. Mégis meglepően gyorsan szokott végezni ezzel a phpMyAdmin, még amikor HDD-n volt az adatbázisszerverem, akkor is mindig meglepett, hogy akár 6500 találat esetén (amelyek több táblában voltak szétszórva) is nagyon gyorsan kész volt (de tény, nem tartok nagyon sokmillió rekordot tartalmazó adatbázisokat a gépemen!). Fogalmam sincs, hogyan van mindez megírva phpMyAdminban, de úgy tűnik, egész értelmesen; majd ha egyszer alkalmad nyílik rá, próbáld ki, csak úgy tesztelés gyanánt.
- hogy miért is lehet szükség minderre. Előfordul, hogy egy alkalmazást nem ismerek még teljesen, és ez felgyorsítja a megismerést. Például amikor egy CMS-ben felviszek néhány adatot sok-sok mezővel, kíváncsi vagyok, konkrétan milyen táblá(k)ba szórja szét azokat (pl. string jellegűeket), így meg rohadt gyorsan megtalálom, és mivel ezután tudom, melyik táblába, melyik mezőbe megy a cuccos, így magában a kódban is gyorsan rá tudok keresgélni, és el tudom kezdeni vizsgálgatni, mi is történik benne; kevesebb agyalás, hogy hol is logikus az egész dolog, kevesebb guglizás. Vagy mittudomén, költöztetted a webalkalmazásodat más domainre, alkönyvtárba, és kíváncsi vagy, vajon vannak-e még hivatkozások a korábbi elérési útra valamelyik tartalomban (például egy WYSIWYG-szerkesztőben a képet bepakoló plugin fosul volt beállítva, és teljes hivatkozásokat tákolt bele a tartalomba). De tudok még nyakatekertebb példákat is. Mindenesetre nem egy hülyeség, hogy ilyesmit lehet egy GUI-n keresztül (ahogy lehet a phpMyAdminban), ahelyett, hogy kézzel kéne összeszenvedni a teljes kódot, mondjuk egy tárolt eljárással, ami tényleg megölheti az SQL-szervert, mert épp készülsz feltalálni a spanyolviaszt.

Sk8erPeter

Sziasztok

Szeretnek egy kis segitseget kerni.

Itt a jelenlegi kodom:
$db->query("SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end` FROM `discounts` WHERE `date_start` <= $currtime AND `date_end` >= $currtime ORDER BY `id` DESC LIMIT 4");

A mezoben van mondjuk:
gametypeid=1 packetid=1
gametypeid=1 packetid=2
gametypeid=2 packetid=3
gametypeid=2 packetid=4

Azt szeretnem megvalositani, hogy csak a:
gametypeid=1 packetid=1 es
gametypeid=2 packetid=3
sorokat valassza ki, tehat gametypeid alapjan, mindegyik gametypeid-bol csak 1 darabot es a legkisebb packetid-jut.

Tudnatok segiteni?

Igazából amiket írtál, csak kódformába kellett önteni (a zárójeleket az átláthatóság kedvéért pakoltam bele pluszban):

SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE
(
`date_start` <= $currtime
AND
`date_end` >= $currtime
)
AND (
( gametypeid=1 AND packetid=1 ) OR
( gametypeid=2 AND packetid=3 )
)
ORDER BY `id` DESC LIMIT 4

Szerk.:
persze itt a gametypeid és a packetid "be van drótozva", ha a hozzá tartozó "legkisebb packetid-jut" szeretnéd automatikusan kideríteni, akkor ahhoz egy bonyolultabb alselectre lenne még szükség.

[ Szerkesztve ]

Sk8erPeter

Igen, de a gametypeid es a packetid folyamatosan valtozni fog, tehat igazabol az egyedi gametypeid-re vagyok kivancsi.

Szerintem group-old gametypeid szerint.
A packetid helyett pedig a MIN(packetid) AS packetid -t rakd a selectbe

- http://pazsitz.hu -

Köszönöm a tanácsot, nem is használom.
Ami miatt most előkaptam, hogy hirtelen kíváncsi voltam valamire, és ha már telepítve van, megnéztem, van-e benne ilyen lehetőség, mert jobb' szeretnék faszányos asztali klienst használni, mint a böngészőben használható phpMyAdmint.
Egyébként a programra ajánlottam alternatívát is, ami szerintem tényleg fasza, nem csak a levegőbe hőbörögtem, a dbForge Studio for MySQL-t, csak azzal az a gáz, hogy fizetős.

"A múltkor konkrétan pl. azért volt rossz, mert te 1-2 funkciót nem találtál meg benne elsőre."
Ilyen mikor volt?
Szerintem erre gondolsz: [link]. Megmutatod nekem, hogy hol írtad le ezekre a megoldást, hogy hol találhatók meg a felületen? Segítek: sehol. Ha megírod, hogy ezek hol találhatók meg, és kiderül, hogy csak az én figyelmemet kerülték el, akkor azt mondom, sorry, én voltam a figyelmetlen, addig viszont ezek továbbra is nyitott kérdések, tények. Szóval?

Sk8erPeter

Ha már ilyen nagy trollá léptem elő: [link]
[link] -> [link]
[link]

[ Szerkesztve ]

- http://pazsitz.hu -

Megprobaltam a group by-t de semmi nem jott be

SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end` FROM `discounts` GROUP BY `gametypeid`; WHERE `date_start` <= $currtime AND `date_end` >= $currtime ORDER BY `id` DESC LIMIT 4

Mi lehet a baj?

Egy mysql hibának kellett volna.
A GROUP BY a WHERE után következik [link]
FROM ... WHERE ... GROUP BY ... ORDER BY ... LIMIT ...;

SELECT `id`, `gametypeid`,MIN(`packetid`) AS `packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE `date_start` <= $currtime AND `date_end` >= $currtime
GROUP BY `gametypeid`
ORDER BY `id` DESC
LIMIT 4;

U.i.: meg most nézem a group by mögött benne maradt még egy pontosvessző is a query-ben.

[ Szerkesztve ]

- http://pazsitz.hu -

CMS-nél tényleg hasznos lehet bizonyos esetekben egy ilyen feature. Én mondjuk olyan mélységben sose használtam CMS-t, mint te. Ellenben én meg minden táblámat ismerek, azaz fel sem merül, hogy vajon hol melyikben kezdjek keresni egy-egy értéket.

Én kérek elnézést!

Fantasztikus, tokeletesen mukodik, koszonom szepen

Sziasztok!

Meg szeretném számolni, hogy kinek van a legtöbb bejegyzése a naplo táblában.
Számomra az bonyolítja a helyzetet, hogy egy ügyfelet nem egyértelműen határozza meg az "account", kell neki a "line" mező is! Ha a count(account)-ot használom az nem jó, mert beleszámol olyat is akinek más a "line" mezője.
Pl létezik ilyen az adatbázisban hogy:
account=1855 line=3
Értéke: Béla
account=1855 line=1
Értéke: Jani

SELECT ugyfel.account AS account,
ugyfel.line AS line,
ugyfel.name1 AS name,
ugyfel.address3 AS irszam,
ugyfel.address1 AS varos,
ugyfel.address2 AS utca,
COUNT(ugyfel.account) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
GROUP BY account,line
ORDER BY darab DESC

előre is köszi!

Ó, tényleg, akkor a júzerek kezelésével kapcsolatban én voltam a figyelmetlen, sorry (ahogy ígértem, leírtam ), legalább ez megoldott kérdés, mégsem olyan "ostoba szar" a progi. (Csak a kedvedért használtam ismét ezt a kifejezést. Mivel úgy csináltál, mintha a korábban belinkelt hozzászólásaimban ne soroltam volna el azokat a dolgokat, amik viszont tetszenek a MySQL Workbench-ben, pedig de.) A gyökereknek szóló lmgtfy-s linkedet pedig külön köszönöm, eddig fogalmam sem volt, hogy kell ilyesmit a Gúúgölben keresni.

A tömörített, gzippelt SQL-dumpokat viszont továbbra sem lehet importálni, most próbáltam, itt, mielőtt ismét küldenél egy lmgty-s linket:

Eredménye:

Pedig ez manapság elég alapvető elvárás, és ez megint csak olyan, amit a phpMyAdmin vicces, hogy tud, ez pedig nem.
Ja, várj, szerinted ez is nyilvánvalóan egy hatalmas baromság, ahogy korábban kifejtetted, hát ki a büdös franc akarna manapság nagyobb adatbázist tömörítve letölteni az eredeti szerverről, és átvinni egy másikra, miért is ne tartaná a terpeszkedő eredeti .sql-formában, hát ki az a hülye, aki ilyesmit manapság csinál, nyilván ez is csak egy játékszer, az ilyenek azzal játsszanak inkább, ami velük egyidős. Ha így látod, hát nagyon rosszul látod.

Sk8erPeter

Emlekeim szerint nem irtam, h tudna ilyet, tovabba azt sem, h felesleges. De nem vagyok benne biztos, h kitomoritve nem tud egyszerre tobb sql dumpot is felnyalni.

- http://pazsitz.hu -

Valóban, nem hülyeségnek tartottad, rosszul emlékeztem, de ezt írtad:
"Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez."
Azért akkora gond, mert ha én tömörített formában exportálom az eredeti szerverről a dumpot, akkor szeretném azt egyből importálni. Nem tudom, mit nem lehet ezen belátni.

A kitömörített változat esélyes, hogy működik, majd kipróbálom. De már megint olyan dolog, amivel nekem kell tökölni, ahelyett, hogy a program elintézné ezt helyettem. Szerintem ez alapvető elvárás, és annyira nem nagy dolog, ha a phpMyAdmin is képes rá.

"A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul..."
Ja igen, erre írtad, hogy ez szerinted f@szság. Hát nem az, és például kapcsolatok gyors létrehozására a phpMyAdminban is van lehetőség grafikus felületen keresztül is.
Mondjuk erre már korábban is reagáltam, hogy kár, hogy nem tudsz olyan esetet elképzelni, ahol a grafikus query-összeállító igen hasznos tud lenni. Nyilván nagyvállalati környezetben (nem magamról beszélek), egy 200 táblás query-összekapcsolást is bepötyögnek, igaz? Szerintem ott is tök jókat "eljátszanak" grafikus alapú adatbázis-kezelőkkel...

Sk8erPeter

Belátom.
Nem tudom mit lehet nem belátni azon, hogy ez másnak (nekem legalább is) ez nem egy elgördíthetetlen akadály.
gunzip < [sqls.gz] | mysql -u [uname] -p[pass] [dbname]

Ja igen, erre írtad, hogy ez szerinted f@szság
Nem így írtam és túlzásnak érzem ezt a kifejezést. Nem az, csak én nem látom igazi hasznát.
De lehet én szoktam az utóbbi időben túlzottan konzolhoz.
( ma is megkaptam, hogy miért akarok konzolból verziókezelőzni, mindenki GUI klienst használ hozzá )

Nagyvállalati környezetről eddig nincs releváns tapasztalatom, 200 táblás összekapcsolással kapcsolatosan sem.
Egyébként szerintem meg nem. De majd hátha van valaki, aki nagyvállalatokban jártas és megmondja nekünk.

[ Szerkesztve ]

- http://pazsitz.hu -

analitikus függvények

SELECT DISTINCT
ugyfel.account AS account,
ugyfel.line AS line,
ugyfel.name1 AS name,
ugyfel.address3 AS irszam,
ugyfel.address1 AS varos,
ugyfel.address2 AS utca,
COUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
ORDER BY darab DESC

COUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) jelentése:

Csoportosítod a rekordokat: az ugyfel.account + ugyfel.line kombó minden csoportot egyértelműen azonosít. A COUNT(*) ezekre a csoportokra vonatkozik. DISTINCT pedig azért kell, mert enélkül a csoportok minden egyes rekordja új sort generálna (azonos tartalommal).

megj.: Erre szerintem az ORDER BY darab DESC nem működik (bár én csak sima SQL-t használok). Allekérdezéssel ez is áthidalható.

[ Szerkesztve ]

Sziasztok

A LIKE-al lehetséges, olyan lekérdezést létrehozni, ahol megnézi, hogy van e az adott kód az adatbázisban majd erre egyértelmű választ ad (1 vagy 0) és kiírja a kódhoz tartozó másik adatot (ebben az esetben nevet).

Vagy ehhez más parancs használatos?

Köszönöm!

[ Szerkesztve ]

Szia!

Köszönöm kimerítő válaszod!
Egyenlőre syntax error-t kapok a:

COUNT(*) over (PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplo

kód környékére... Átnéztem a mysql ezen parancsára vonatkozó szintaxist, de szerintem ennek jónak kéne lenni. Tanácsodra elhagytam az order by parancsot is, de nincs változás...
vmi ötlet?

Ez biztos MySQL szintaktika?

Én kérek elnézést!

Kétlem. Az előbb amúgy Apollo17hu írta is, hogy "csak sima SQL-t használok", meg belinkelte az "Oracle Database SQL Reference"-t.

(#1042) p06 : "Perl-ben lekérdezem a teljes adatbázist egy táblába majd egyenként összehasonlítok és értékelek"
Nyami.

[ Szerkesztve ]

Sk8erPeter

Jaj ne már... magadat sem veheted komolyan. Gizdulásnak is gyenge volt ez a gunzipes példád. Könyörgöm, tényleg ily' nehéz megértened, hogy itt GUI-n keresztüli adatbázis-manipulálásról volt szó, anélkül, hogy hozzányúlnál egyáltalán a konzolhoz/terminálhoz?
Minek kötöd az ebet a karóhoz?
Ilyen alapon a júzerek létrehozására, privilégiumainak módosítására is írhatnék akár egy konzolos kis progit C-ben, vagy sima batch-programot, biztos rendkívül izgi lenne, meg feltalálhatnám a spanyolviaszt. Körbeírjam még párféleképpen, hogy mi itt az alapvető probléma?

"Egyébként szerintem meg nem."
Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz?

Sk8erPeter

Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz?

Hol létezik olyan, hogy 100 táblát kell joinolni?

Az előbb már írtam: nagyvállalati környezetben, bizonyos adatok kinyerése érdekében, naplózáshoz és egyéb célokhoz is. Ha nem hiszed, megadom az elérhetőségeit egyik haveromnak, ha szeretnél vele erről diskurálni, hogy egy németországi rohadt nagy cégnél miért művelnek ilyen elmebeteg dolgokat. Először én is le voltam hidalva a számokon, amikről mesélt. De félreértés ne essék, NEM MySQL-ben dolgoznak.

Sk8erPeter

Sziasztok

A gépen fut egy teljesen alap LAMP. Itt az adatbázisban vannak az adatok amik kellenek és a követklező sorok segítségével le is tudom kérdezni Perl-ben:

#!/usr/bin/perl

use DBI;
use DBD::mysql;

$platform = "mysql";
$database = "kartyak";
$host = "localhost";
$port = "3306";
$tablename = "Jog";
$user = "root";
$pw = "1234";

$dsn = "dbi:mysql:$database:localhost:3306";

$connect = DBI->connect($dsn, $user, $pw);

De én egy másik eszközön szeretném ellérni ezt a program segítségével (böngészőből működik). Mit kell beállítanom? (Probálkoztam azzal, hogy a $host-hoz beírtam az adott gép IP-jét de hiba volt nem tudott belépni)

Előre is köszönöm!!