- Fotók, videók mobillal
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Milyen okostelefont vegyek?
- Az iPhone hajthatatlanságán gúnyolódik a Samsung
- Poco F7 Pro - jó, de az amatőr sem rossz
- Google Pixel topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Megjött a jubileumi Pixel széria
- iPhone topik
- Végre bemutatkozott a Pixel 8 és a Pixel 8 Pro
Új hozzászólás Aktív témák
-
#1400
Peter Kiss
őstag
Drótszamár
#1399
Peter Kiss
őstag
válasz
Drótszamár
#1399
üzenetére
InnoDB jobban bírja az INSERT-et.
---
Ez a két index haszontalan, 1-1 oszlop nagyon ritkán jó külön indexelve, készíts olyat, amiben az első oszlop a muszer_id és a második a datum. És azon túl, hogy haszontalan, feleslegesen rontja az insert-teljesítményt is.
Az ellenőrzésed nem tudom, hogyan néz ki pontosan, de a fenti query-t alapul véve inkább egy kellene:
SELECT dátum FROM tábla WHERE (műszer_id="xxx") and (dátum="2013.08.18 18:00:00" or dátum="...") LIMIT 1;
Vagy lehetne még EXISTS-et is használni.
Emellett nem tudom, hogyan futtatod ezeket? 1 INSERT előtt 1 SELECT? Lehet, hogy érdemes lenne előbb lemarni az összes kizáró tényezőt alkalmazás szinten, ha lehet, majd csak a ténylegesen beszúrandókat elküldeni, és így 2 hívásból megvan az egész.
---
Utolsó dolog, amire figyelni kellene, az a szerver beállítása, helyből a MySQL egy 10+ éves gépre van optimalizálva 5 MB memóriával.
-
#1399
Drótszamár
őstag
Peter Kiss
#1398
Drótszamár
őstag
válasz
Peter Kiss
#1398
üzenetére
datum BTREE
Egyedi: Nem
Csomagolt: Nem
Számosság: 126492
Illesztés: A
Nulla: YESmuszer_id BTREE
Egyedi: Nem
Csomagolt: Nem
Számosság: 1
Illesztés: A
Nulla: YESMegszokásból MyISAM. Van erre a feladatra jobb tároló?
-
#1398
Peter Kiss
őstag
Drótszamár
#1397
Peter Kiss
őstag
válasz
Drótszamár
#1397
üzenetére
Pontosan hogyan néz ki az index, és miért MYISAM?
-
#1397
Drótszamár
őstag
Drótszamár
őstag
Üdv!
PHP + APACHE + MYSQL
Mérési adatokat kellene egy táblázatban tárolnom. Ritkán jön bele adat, de akkor sok. Egyszerre 10-20.000 adat érkezik, a tábla milliósra fog hízni idővel.
Van hozzá egy fapados tábla
ID, műszer_id, dátum, adat, küldés dátum.
A dupla tárolást úgy próbálom szűrni, hogy az insert előtt egy select-tel megnézem van e már erre a dátumra mérési adat.
SELECT dátum FROM tábla WHERE (műszer_id="xxx") and (dátum="2013.08.18 18:00:00" or dátum="..."); Maga a query rohadt nagy, 10-20.000 adatot kérek le egyszerre.
Kb 100.000 adatnál járok, és egyre lassul a törénet.
index van a műszer_id-re, és a dátumra is. MYSAM tábla.
Konfiguráción állítsak, vagy a logika a hibás? Hol a lassulás oka? A lekérdezés lassú, vagy az értelmezés is az pl a 10.000 "szöveges" dátum miatt? Vagy írjam át a kódot, és egyesével kérdezzem le?
Egy hasonló logika alapján felépített insert lefut egy fél pillanat alatt...
-
#1396
Jim-Y
veterán
Apollo17hu
#1395
Jim-Y
veterán
válasz
Apollo17hu
#1395
üzenetére
Szia, igen jól működik köszönöm
http://sqlfiddle.com/#!2/588bd6/14 -
#1395
Apollo17hu
őstag
Jim-Y
#1394
Apollo17hu
őstag
Akkor átírva a fentit ez jó?
SELECT t2.range_from
,t2.range_to
,MIN(CASE
WHEN t2.range_from >= t1.range_from AND t2.range_to <= t1.range_to THEN
'I'
ELSE
'N'
END) flag
FROM t1
,t2
GROUP BY t2.range_from
,t2.range_toszerk.: Tényleg jó a Fiddle, külön öröm, hogy van benne kódformázás is.
-
#1394
Jim-Y
veterán
Sk8erPeter
#1393
Jim-Y
veterán
válasz
Sk8erPeter
#1393
üzenetére
Még nem tudtam kipróbálni a kapott választ ezért nem válaszoltam, majd jövő héten.
Azok a tartományok, amik bővebbek, és amikből kevesebb van, azokat csv fájlokban kapok(unk) meg, és azt is egy ETL eszközzel töltjük be az adatbázisba. Időnként frissül. Az a tábla, ahol ezresek a felbontások, azt már én hoztam létre, mert az elvárás az, hogy ezres legyen a felbontás, ne pedig változó.
Az a feladat, hogy abban a táblában, ahol a bővebb felbontások vannak, 1-1 ilyen felbontásra meg van határozva valami, a példa kedvéért legyen az, hogy 'Fontos', 'Nem fontos'
Na, kipróbáltam az SQLFiddle-t, jó cucc, nem hallottam még róla
http://sqlfiddle.com/#!2/588bd6/3
És akkor talán így már világos a feladat is. T2 'range_jelolo' oszlopát szeretném feltölteni T1 'Jelolo' oszlopa alapján.
-
#1393
Sk8erPeter
nagyúr
Jim-Y
#1390
-
#1392
Apollo17hu
őstag
Jim-Y
#1390
Apollo17hu
őstag
SELECT tabla_1.col1
,tabla_2.col2
,MIN(CASE
WHEN tabla_1.col_1 >= tabla_2.col_1 AND tabla_1.col_2 <= tabla_2.col_2 THEN
'I'
ELSE
'N'
END) flag
FROM tabla_1
,tabla_2
GROUP BY tabla_1.col1
,tabla_2.col2Itt nem 'TRUE' jelenik meg, hanem 'I', ha a 2. táblában legalább egy olyan tartomány van, amibe beleesik, 'N' pedig, ha nincs ilyen tartomány.
Nem ellenőriztem, próbálgasd...
Az elv az, hogy a Descartes-szorzatot a MIN() függvénnyel redukálod (méghozzá az 1. táblában szereplő sorok számára). A MIN() azért jó, mert az 'I' karakter előbb van az ABC-ben mint az 'N' karakter.
-
Jim-Y
veterán
sziasztok
Egy olyan problémába ütköztem, hogy van két táblám, mindkét táblában van két oszlop ami egy-egy tartományt jelöl ki
Példa:
Tábla 1:
Col1 Col2
1000 1999
2000 2999
3000 3999
...Tábla 2:
Col1 Col2
1000 5999
9000 17999
53000 120999
123000 124999
....Tábla1 a több soros, mivel itt ezresével vannak felbontva a tartományok (Range-ek)
Tábla2 kevesebb soros, ebben különböző méretű tartományok vannak.Tábla1-be, vagy egy új tábláva szeretnék bevezetni egy olyan oszlopot, hogy ha Tábla 1 tartománya beleesik Tábla 2 valamely tartományába, akkor az oszlop értéke legyen mondjuk true, ha nem akkor false.
Nem tudom, hogy érthető-e, a lényeg, hogy pl 1000 - 1999 beleesik-e Tábla 2 valameny tartományába (pl 9000 17999), ha belesik, akkor Tábla1 azon sorában ahol a tartomány van felvennék egy új oszlopot.
Remélem tudtok segíteni.
Jelenleg az a gond, hogy descart szorzattal fűzöm össze a két táblát, ilyenkor ugye végigiterál az össze soron.
Pl 1000-1999 tegyük fel beleesik Tábla 2 legelső tartományába, akkor nekem itt meg kéne állnom, és menni a következő sorra, mert most még végigmegy a többi soron, és ott nyílván már nem fog belesni a range-be így helytelen eredményt kapok :S
-
Lacces
őstag
Hali,
Az lehetséges, hogy úgy kapok egy unique-al ellátott oszlopra duplicalt entry hibát, hogy az az érték sosem volt előtte benne az adatbázisban? Mert kidobta ezt a hibát, de el is mentette az adatokat. De elméletben én úgy tom, hogy nem is kellene, akkor adatokat mentenie sem.
És ez egyszeri esetnek tűnik... -
Jim-Y
veterán
Sziasztok.
Egy ETL eszközzel töltök egy már meglévő táblához új adatokat úgy, hogy az eredeti táblát ki kellett egészítenem 2 új oszloppal, mert az új betöltésben már van két plusz oszlop.
Először ALTER tablellel hozzáadtam a kívánt két új oszlopot NULL default value-val, majd betöltöttem az adatokat.
Az eredmény az lett, hogy a régi táblában az új oszlopoknál null érték szerepel, az új soroknál pedig jó értékek. Igen ám, de ha lefuttatok egy lekérdezést, akkor ezek az új adatok is 'átállítódnak' null értékre.Kérlek ne nézzetek hülyének, én sem értem, hogy ha lefuttatom a selectet betöltés után akkor a jó értékek szerepelnek, ha írok a táblára egy query-t, lefuttatom (nem lesz jó az eredmény), majd lefuttatom megint a select * -ot akkor már nem jó értékek vannak benne, hanem csupa NULL.
Találkozott már valaki ilyennel?
-
#1385
bpx
őstag
Speeedfire
#1384
bpx
őstag
válasz
Speeedfire
#1384
üzenetére
-
#1384
Speeedfire
félisten
Speeedfire
félisten
Linux alatt, hogy tudok mysql jelszót cserélni parancssorban? Szerintem valami program tegnap felülcsapta amit beállítottam, ma meg már nem megy.
Nem akar beengedni.
-
szmegma
aktív tag
az a baj a mysqllel, hogy nincs benne egyszeru "generator" funkcio...
Mondjuk ez tenyleg gaz.
Ugy sem megoldhato, hogy PHP generalna ki egy tombbe a datumokat es azt "tolteni be" a lekerdezesbe?A PHP tomb kimenete a 31 nap datuma:
$dates[] = '2013-08-01';
$dates[] = '2013-08-02';
$dates[] = '2013-08-03';
...MYSQL:
SET dates = '$dates';
date_add(CURDATE(), interval n.n day)
FROM dates nCsak kerdezem, mivel nem tudok rola szinte semmit.
Sk8erPeter Az tuti, hogy ugy lenne jo megcsinalni, hogy nem kene meg evente sem hozzanyulni.
-
#1382
martonx
veterán
Sk8erPeter
#1381
martonx
veterán
válasz
Sk8erPeter
#1381
üzenetére
Ez igaz, de tudod mikor jut eszedbe minden évente, vagy két évente utánhúzni?
Mi pont idén szívtunk ezzel, amikor 5 évvel ezelőtt 5 évre előre belőttük az adatokat, aztán valamikor májusban tűnt fel elöször, hogy év eleje óta szarul számol pár algoritmus. -
#1381
Sk8erPeter
nagyúr
martonx
#1376
-
#1378
Apollo17hu
őstag
bpx
#1377
Apollo17hu
őstag
ez a feladat pl. arra is lefordithato, hogy generaljunk szamokat 1-31-ig es adjunk hozza ennyi napot a mostani datumhoz, ami tisztan SQL lenne
Pont ezt javasoltam neki én is, lévén MySQL-hez nem konyítok.
Az az Oracle-s kód a hsz.-ed végén tetszik, köszi. (Én mindig egy számokat tartalmazó segédtáblával oldottam meg eddig a hasonló problémákat.)
-
bpx
őstag
válasz
szmegma
#1360
üzenetére
az a baj a mysqllel, hogy nincs benne egyszeru "generator" funkcio, mert egyebkent ez a feladat pl. arra is lefordithato, hogy generaljunk szamokat 1-31-ig es adjunk hozza ennyi napot a mostani datumhoz, ami tisztan SQL lenne
de rekurziv lekerdezessel megoldhato, csak kell egy olyan forras, amelynek legalabb 31 sora van
peldaul select SQL megoldas:select date_add(CURDATE(), interval o.num day) from
(select @n := @n + 1 as num
from information_schema.columns, (select @n := 0) n
limit 31) o;ezzel persze az a baj, hogy mindig az information_schema.columns-hoz (vagy amire epp meg van irva) kell nyulni + akar el is lehetne tarolni a szamokat 1-31-ig egy kulon tablaban (es nem kell feltalalni ujra a kereket naptar tablaval):
create table numbers (n int);
insert into numbers
select @n := @n + 1 as num
from information_schema.columns, (select @n := 0) n
limit 31;
select date_add(CURDATE(), interval n.n day) from numbers n;csak hat ez meg megint ronda (szerintem)
szemlelteteskeppen, Oracle-ben ez ennyi:
select sysdate + level from dual connect by level <= 31;
a dual tabla sajatossagai miatt ez raadasul sem diszkrol, sem a cache-bol nem olvas, nem kell PL/SQL-ezni meg context switch sincs
-
#1376
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Nem is konkrét buktatókra gondoltam, hanem pl. az összes ünnepnapot, különös tekintettel a mozgó ünnepekre, mondjuk húsz évre előre meghatározni, elég babra munka tud lenni.
Azaz a végeredmény nem annyi, hogy egy szép nagy insert-tel feltöltesz minden napot, hanem utána az ünnepnapok, munkaszüneti napok, munkanap áthelyezések, hosszú hétvégék a macerásak. -
#1375
Jim-Y
veterán
Sk8erPeter
#1374
Jim-Y
veterán
válasz
Sk8erPeter
#1374
üzenetére
Végül tárolt eljárás lett belőle. Azért megosztom hátha valamire még használni lehet
DELIMITER $$
DROP PROCEDURE IF EXISTS `ranges` $$
CREATE DEFINER=`user`@`%` PROCEDURE `ranges`()
BEGIN
DECLARE v1 INT DEFAULT 2000000;
WHILE v1 < 9999999 DO
INSERT INTO test_table(range_from, range_to) VALUES (v1, v1+999);
SET v1 = v1 + 1000;
END WHILE;
END $$
DELIMITER ; -
#1373
Sk8erPeter
nagyúr
martonx
#1361
Sk8erPeter
nagyúr
válasz
martonx
#1361
üzenetére
"noha nem kis munka egy tisztességes naptár táblát összerakni pár évre előre magadnak"
Most ezen agyaltam, mik lehetnek a buktatók?
Amúgy mintha itt az emberke pont ilyesmivel foglalkozna, hogy mikor vannak szünnapok, stb., bár a cikk minőségét nem néztem, csak gyorsan beletekergettem kíváncsiságból.
Ilyesmikre egyébként vannak kész célszoftverek, nem? -
#1372
Sk8erPeter
nagyúr
fordfairlane
#1368
Sk8erPeter
nagyúr
válasz
fordfairlane
#1368
üzenetére
Bocs, hogy ezt mondom, de engem meg speciel sokkal jobban zavar az, hogy majd' minden webfejlesztős topicban előadod a Prohardver ügyvédjét, meg a "jaj nem is hiszem el, hogy mik mennek manapság, nem is fogom követni a topicot"-sirámot, mintha a kérdezők a segítségedre szorulnának, amikor valaki nem pont finomkodva tesz valami erősebb megjegyzést, és ezt kell elég sokszor olvasni tőled. Hidd el, a segítséged nélkül is általában meg tudják védeni magukat, nem kell mindig a haladó(bba)kkal összeveszni azon, hogy miért nem porcelánbabák módjára bánunk egymással. Az ilyeneken való hosszas OFF-olások legtöbbször rosszabbak, mint maguk a beszólások.
(Pedig egy haladónak ugyanannyi joga van - nem feltétlenül jogosan! - beszólni valakinek, aki esetleg nem nézett utána rendesen, vagy furát kérdezett; de igaz, neked is természetesen van jogod beszólni a beszólásért 
csak nem biztos, hogy előrevisz.) Ezt nem sértésként mondtam, ne is vedd kérlek annak! 
-
#1371
martonx
veterán
fordfairlane
#1370
martonx
veterán
válasz
fordfairlane
#1370
üzenetére
Az esetleges fellengzős hozzászólásomért veled ellentétben én bocsánatot kértem. Arról pedig nem vagyok hajlandó flame-et folytatni, hogy bizonyos esetekben (bizonyos szektorokban ezek a bizonyos esetek mindennapiak, más szektorokban meg szökő évente jönnek csak elő) miért nélkülözhetetlen egy jól megírt tárolt eljárás.
-
#1370
fordfairlane
veterán
martonx
#1369
fordfairlane
veterán
válasz
martonx
#1369
üzenetére
Nem a tárolt eljárások létjogosultságát vagy hasznosságát kérdőjeleztem meg, hanem azt, hogy minek kell azon köröket futni, hogy ki használta és ki nem (és jájjdeámátőr) Sokan nem használják, mert nem a klasszikus Oracle, Sybase, DB2 vagy MSSQL-en tanultak, a Mysql-be meg később került bele. Vagy azért nem használják, mert korlátozottak a lehetőségek és emiatt úgyis szükség van egy alkalmazásszerverre, és ha már van alaklmazásszerver, akkor azon implementálnak minden funkcionalitást. Vagy azért, mert a tárolt eljárások még annyira sem egységesek a különféle vendorok közt, mint az SQL lekérdezések. Nincs azon semmi meglepő, hogy ilyen körülmények közt csomóan nem nyúlnak hozzá, csak ha muszáj.
-
#1369
martonx
veterán
fordfairlane
#1368
martonx
veterán
válasz
fordfairlane
#1368
üzenetére
Nem én írtam butaságot, hanem te, szóval elég lett volna vagy csak simán csöndbe maradnod, vagy bocsánatot kérni szmegma-tól, ha a beírásod miatt ismét hetekig próbálkozik tovább tárolt eljárás nélkül.
Ha esetleg arcoskodóra sikerültek volna az előző hozzászólásaim, akkor elnézést kérek mindenkitől.Az, hogy használjunk-e tárolt eljárásokat vagy sem, örök vitatéma, hetekig lehetne flamelni róla. Az esetek jó részében valóban el lehet lenni nélküle, viszont pont az szmegma-féle komplexebb lekérdezéseknél meg megkerülhetetlen a használata.
-
#1367
martonx
veterán
fordfairlane
#1366
martonx
veterán
válasz
fordfairlane
#1366
üzenetére
Hehe, ez vicces megjegyzés volt. Attól, hogy te még nem használtad, ugyan próbálj már meg komolyabb logikát összerakni SQL-ben tárolt eljárás nélkül. Elhiszem, hogy kismillió olyan projekt van, amikben a két táblás alkalmazásnál a select * from tábla a maximum, amit használni kell. Ettől még hidd el vannak akik főállásban tárolt eljárásokat írnak, és nem azért mert éppen olyanjuk van.
-
Jim-Y
veterán
Sziasztok!
Lenne egy olyan feladatom, hogy egy tartományt kéne feldarabolnom 1000-es szeletekre.
Példa:
from | to
2000 2999
3000 3999
5000 5999
stb...Ugye ez eddig egyszerű, ciklus, a ciklusváltozó 999-el növekszik, onnantól pedig megvan.
A kérdésem az lenne, hogy van-e erre valami szebb megoldás, illetve miben kéne ezt megcsinálnom? Tárolt eljárás, valamilyen ETL eszköz?
köszi
-
martonx
veterán
válasz
szmegma
#1360
üzenetére
Hirtelenjében két módszer jutott az eszembe.
1. While ciklussal - SQL-ben ez nem túl szép, de ez pont az az eset, amikor érdemes használni.
2. Csinálsz magadnak egy naptár táblát, amibe pár évre előre eltárolod a napokat, hétvégéket, munkaszüneti napokat.Ismerve, hogy ez mihez kell neked, én a második megoldást javaslom, noha nem kis munka egy tisztességes naptár táblát összerakni pár évre előre magadnak.
-
szmegma
aktív tag
Na akkor egy temaba illo kerdes.
Pusztan pelda ertekkel biro kod, mivel fingom sincs:SELECT BETWEEN (DATE(CURDATE()+1) AND DATE_ADD(CURDATE()+1, INTERVAL 31 DAY)) AS dates
Hogyan lehet, kimenetkent megkapni a holnapi es azt azt koveto 31 nap datumait (31 darab rekord)? A fenti kodban probaltam szemleltetni, hogy egy hasonlo lekeressel a dates segedoszlopban szeretnem megkapni a kivan 31 nap datumat.
-
#1358
martonx
veterán
Sk8erPeter
#1357
martonx
veterán
válasz
Sk8erPeter
#1357
üzenetére
Ez igaz, csak engem zavar, hogy akármikor benézek, mindig látom, hogy MySQL topikban esemény volt, aztán ide kattintva látom, hogy már megint egy 800 soros hsz. érkezett.
Persze azon el lehet témázni, hogy mi illik ide, meg mi nem. Szvsz a hogyan kell mysql-t telepíteni, meg miért fut le hibásan a select * from table lekérdezésem nem illik ide, mert aki ilyet kérdez, az meg se próbálja az agyát / guglit használni.
Ugyanakkor van az a szakmai mélység is, ami szintén nem illik ide, egyszerűen nem hiszem, hogy egy olyan komplexitású feladat, aminek a normális megfogalmazása, példa adatostól, egy - két alap lekérdezéssel több A4-es lapot venne igénybe, annak a megoldását egy fórum keretein belül kellene kiszenvedni.
Ráadásul most borítékolom, hogy a megoldás sem egy húsz soros sql script lesz a végén, ergo a topik tényleg semmit nem fog profitálni belőle.
Apollo-nak valóban nagy riszpekt érte, hogy ingyen ennyit segít, nem is ellene szólt az észrevételem, csak jeleztem, hogy ha ennyire ráér, meg ennyire érdekli a probléma, akkor vegye fel a kapcsolatot direktben szmegma-val, aztán skypeozzanak, emailezzenek, oldják meg egymás között. -
#1357
Sk8erPeter
nagyúr
martonx
#1352
Sk8erPeter
nagyúr
válasz
martonx
#1352
üzenetére
Speciel én abszolút passzív félként néha beleolvastam az eszmecserébe, igaz, már egy ideje elvesztettem a fonalat, de nem éreztem "vergődésnek", plusz sztem a topic elbírja a beszélgetésüket.
Meg mondjuk jóval érdekesebb problémát járnak körül, mint hogy hogyan kell MySQL-ben levágni egy szóközt a szó elejéről, meg hasonló, mostanában előforduló rendkívül érdekfeszítő kérdések... 
Üdítőbb ezeknél egy érdemi kérdésről témázás, igaz, Apollo17hu lényegében másnak oldja meg a munkáját tök ingyen, mindenesetre a kitartásáért jár neki a virtuális sör. 
-
bbTamas77
aktív tag
phpmyadminba szeretnék importálni, de nem igazán jön össze, ahogy szeretném:
sql utasítás:
LOAD DATA LOCAL INFILE '/blabla/ nev.txt'
INTO TABLE nev
FIELDS TERMINATED BY ':::'
ENCLOSED BY '"';Adatok amit importálni szeretnék:
:::::::::"John":::"Doe"
:::::::::"Albert":::"Smith"
:::::::::"Jimmy":::"Carr"
:::::::::"Anna":::"Bell"Importálás sikerül, viszont a négy rekord helyett csak két rekodot szúr be.
Öt mező van benne, ':::' jelet használok elválasztásra, oda nem írok semmit mert alapértelemzett érték van beállítva.
Shift+Enter használok a sorok közt, akkor se jó. -
#1354
szmegma
aktív tag
Apollo17hu
#1351
szmegma
aktív tag
válasz
Apollo17hu
#1351
üzenetére
Kuldtem uzenetet.
-
#1351
Apollo17hu
őstag
szmegma
#1350
Apollo17hu
őstag
válasz
szmegma
#1350
üzenetére
Igazad van. Az a probléma, hogy én csak arra gondoltam, hogy a vizsgálandó intervallum beleesik-e a már foglalt időintervallumba. Lehet viszont olyan eset is, amikor csak átfedés van.
Módosítsd úgy a feltételt, hogy a foglalt jelzést a következő jelentse:
(workers_start_timestamp > desired_start_time AND workers_start_timestamp < estimated_completion_time)
OR
(workers_finish_timestamp > desired_start_time AND workers_finish_timestamp < estimated_completion_time)Ennek már jónak kell lennie.
-
#1350
szmegma
aktív tag
Apollo17hu
#1348
szmegma
aktív tag
válasz
Apollo17hu
#1348
üzenetére
Eloszor erre valaszolnek, mert lehet talaltam egy hibat a CASE-ben.
Azt szurjuk ugye, hogyworkers_finish_timestamp > estimated_completion_time
AND
workers_start_timestamp < desired_start_time
THEN => 'nem vallalhatja el' <= igaz, ha az AND elotti es utani resz IGAZ
ELSE => 'elvallalhatja' <= igaz, ha az AND elotti es/vagy utani resz HAMISDE! Ez nem minden esetben mutatja a helyes kimenetet (szabad vagy nem szabad a munkas). Pl.:
1, mukodik - kod szerint nem vallalhatja el es ez IGAZ
IF workers_start_timestamp(06:30) < desired_start_time(08:00) <= igaz
AND workers_finish_timestamp(11:30) > estimated_completion_time(10:00) <= igaz2, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(10:00) < desired_start_time(06:00) <= hamis
AND workers_finish_timestamp(15:00) > estimated_completion_time(07:00) <= igaz3, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(08:30) < desired_start_time(08:00) <= hamis
AND workers_finish_timestamp(14:30) > estimated_completion_time(11:00) <= igaz4, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(15:00) < desired_start_time(07:00) <= hamis
AND workers_finish_timestamp(17:00) > estimated_completion_time(13:00) <= igaz5, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(07:30) < desired_start_time(09:00) <= igaz
AND workers_finish_timestamp(10:30) > estimated_completion_time(15:00) <= hamis6, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(13:30) < desired_start_time(09:00) <= hamis
AND workers_finish_timestamp(17:30) > estimated_completion_time(11:00) <= igaz7, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(16:00) < desired_start_time(16:00) <= hamis
AND workers_finish_timestamp(19:00) > estimated_completion_time(19:00) <= hamis8, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(12:30) < desired_start_time(10:30) <= hamis
AND workers_finish_timestamp(15:30) > estimated_completion_time(12:30) <= igazPapirra levezettem par peldat es melle irtam par kezdesi es befejezesi idopontot es a keplet ezek felet jol kezelte, a masik felet rosszul, azert is merultem el jobban benne.
Amit leirtam igazam van, vagy hulyeseget beszelek? -
#1349
Apollo17hu
őstag
szmegma
#1347
Apollo17hu
őstag
válasz
szmegma
#1347
üzenetére
Gondolkodtam, hogyan kellene továbbhaladni. Lehet, hogy túlbonyolítom, de 2 halmazt (lekérdezést) kellene alkotni. Az eddigiekhez képest módosítani kell a meglévő lekérdezésen, lejjebb írom, hogyan:
1. azon munkások, akik munkaidején belülre esik a vizsgálandó időintervallum
2. minden munkás minden munkavégzését minősíteni aszerint, hogy üti-e a vizsgált intervallumot -> ["oszlop"]Az elsőnek vhogy így kell kinéznie:
SELECT DISTINCT workers_id
FROM ...
WHERE munkaido_start < checking_start AND munkaido_end > checking_endEz csak a munkások azonosítóit adja vissza, semmi mást, és másra nincs is szükség.
A második pedig az eddig megírt lekérdezésed módosítása. Annyit kell átírnod benne, hogy a WHERE -ből kitörlöd az eddigi szűréseket, helyette pedig beírod a CASE WHEN tartalmát (és így egyúttal az ["oszlop"] segédoszlopot ki is törölheted). Tehát így:
SELECT DISTINCT workers_id
FROM ...
WHERE munkafolyamat_start < checking_tart AND munkafolyamat_end > checking_endEz csak azokat a munkásokat listázza, akik már foglaltak a vizsgált intervallumot tekintve.
Ha sikerült előállítani a fenti két lekérdezést, akkor LEFT (vagy RIGHT) JOIN-nal kösd össze őket! Az 1. halmazból "kivonva" a 2. halmazt azokat a munkásokat kapod, akik ráérnek a vizsgált időpontban.
Így:
SELECT munkaideje_megfelel.workers_id
FROM (első lekérdezés kódja) AS munkaideje_megfelel
LEFT JOIN (második lekérdezés kódja) AS munkafolyamatat_uti
ON munkaideje_megfelel.workers_id = munkafolyamatat_uti.workers_id
WHERE munkafolyamatat_uti.workers_id IS NULLA JOIN-okban nem vagyok biztos, én más szintaktikát szoktam használni, de a lényeg sztem látszik.
Ha ez kész, akkor írom, hogyan csapd a workers_id mellé a szükséges infót (de erre már te is rá tudsz jönni).
-
#1348
Apollo17hu
őstag
szmegma
#1347
Apollo17hu
őstag
válasz
szmegma
#1347
üzenetére
Ha jol ertem, akkor ez mar CSAK ["oszlop"]=>"true" erteku munkast dob vissza? Magyarul aki biztos nem er ra.
Nem, ["oszlop"] értéke lehet "false" is, ami azt jelenti, hogy a munkásnak ez a munkája nem ütközne abba a munkába, amit rá akarunk sózni. Viszont a munkásnak több munkája is van, és ha csak egynél is "true" értéket kapsz, az fogja azt jelenteni, hogy a munkásnak van olyan munkája, ami üti a rásózandó melót. De át is írhatod a "true" és a "false" értékeket pl. "not feasible" és NULL -ra vagy bármire, hogy hangsúlyosabban látszódjon.
Idokozben kiderult itt egy ujabb dolog. Megpedig, hogy nem csak egyetlen idopontot kell vizsgalnia a keresnek, hanem ido intervallumot.
Ezt úgy kellene megoldani, hogy az intervallum kezdetét és végét tárolod. Tehát mondjuk checking_start és checking_end meződ van. Az ["oszlop"] meződet kell csak módosítanod (ennek is adhatnál mondjuk egy ["check_worker_time"] vagy bármilyen, beszédes nevet) úgy, hogy a checking_start -ot a workers_start_hour -hoz, a checking_end -et pedig a workers_end_hour -hoz viszonyítod.
-
#1347
szmegma
aktív tag
Apollo17hu
#1343
szmegma
aktív tag
válasz
Apollo17hu
#1343
üzenetére
...a workers_starting és workers_finishing mit jelent?
A workers_starting az a munkas elso foglalt idopontjat jelzi (pl., 2013-09-10 08:00:00), a workers_finishing pedig a munkas utolso foglalt idopontja (pl., 2013-09-10 11:00:00). Szoval ha csak o lenne egyedul a cegnel, es vki rendelest akarna leadni 11:00 orara, akkor a fenti pelda alapjan leadhatja, mivel a munkas 11 orakor mar raer.
Magyarul, az adott munkas CSAK a workers_starting és workers_finishing idokozott nem er ra, elotte es utana raer.Megcsinaltam amit irtal WHERE kriteriumot es ezt dobta a MySQL eredmenykent:
array(11) {
["booking_id"]=>"4"
["cheking_time"]=>"11:30"
["jobs_id"]=>"4"
["starting_timestamp"]=>"1366884000"
["number"]=>"8"
["workers_id"]=>"2"
["workers_start_hour"]=>"09:30"
["workers_finish_hour"]=>"18:30"
["workers_working_date"]=>"2013-04-25"
["interval_start"]=>"2013-07-28"
["interval_end"]=>"2013-08-28"
["oszlop"]=>"true"
}Ha jol ertem, akkor ez mar CSAK ["oszlop"]=>"true" erteku munkast dob vissza? Magyarul aki biztos nem er ra.
Idokozben kiderult itt egy ujabb dolog. Megpedig, hogy nem csak egyetlen idopontot kell vizsgalnia a keresnek, hanem ido intervallumot.
Szoval nem csak a 8 orai pillanatot kell ellenorizni, hanem a kivalasztott munka hosszatol fuggoen, a 08:00-tol, a munka befejezeseig terjedo intervallomot kellene vizsgalni.
Tehat amikor kivalasztja vki a 08:00, akkor mar adott, (korabban beallitott) hogy meddig fog a munka tartani.
Pl., 3 oras, tehat 08:00 es 11:00 ora kozotti idopontokat kell vizsgalni, hogy ne fedje legalabb egy munkas foglaltnak jelzett idointervallumjat.Remelem ez az apro valtozas tul sokat nem erinti az eddig elkeszitett projectet.
Ha a fenti kod jol mukodik, vagyis az elgondolasod szerint, akkor most mi a kovetkezo lepes?Koszonom.
-
bbTamas77
aktív tag
Üdv éppen mysql tanulgatom és máris gondom akadt.
php myadmint használok, Verziószám: 3.5.2.2, utolsó stabil verzió: 4.0.4.1
Szerintem hibátlanul írtam mindent de mégis hibát ír ki.
Amikor az első táblát létre akarom hozni akkor még nem írt ki semmit, sikeresen létrehozta:
Első tábla.
Create Table nev (
nev_id SMALLINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
new_addatum DATETIME DEFAULT '0000-00-00 00:00:00',
new_moddatum DATETIME DEFAULT '0000-00-00 00:00:00',
vezeteknev VARCHAR (75),
keresztnev VARCHAR (75),
INDEX idx_vn (vezeteknev),
INDEX idx_kn (keresztnev)
);De amikor a második táblát hoznám létre sql parancs segítségével, akkor php myadmin az alábbi hibát írja ki.
Második tábla és a hiba:Create Table munkahelyi_beosztas (
beosztas_id SMALLINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
new_id SMALLINT UNSIGNED NOT NULL DEFAULT '0'
beosztas_addatum DATETIME DEFAULT '0000-00-00 00:00:00', beosztas_moddatum DATETIME DEFAULT '0000-00-00 00:00:00',
beosztas_nev VARCHAR (100),
INDEX idx_beoszt (beosztas_nev)
);Hibaüzenet.
#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 'beosztas_addatum DATETIME DEFAULT '0000-00-00 00:00:00', beosztas_moddatum DAT' at line 4Értem én, hogy azt írja hogy verzióhiba, de mégis hogyan lehetne másképpen megadni, hogy elfogadja az alapértelmezett értéket?
-
#1343
Apollo17hu
őstag
szmegma
#1342
Apollo17hu
őstag
válasz
szmegma
#1342
üzenetére
Várjál, ez így még nem biztos, hogy jó. Nézem az új kódod: abban a workers_starting és workers_finishing mit jelent? A teljes vagy csak a foglalt munkaidő kezdetét és végét? Ha utóbbit, akkor jó, ha előbbit, akkor ki kell cserélni, mert a foglalt munkaidőt kell összevetni a checking_time -mal.
Ezután a lekérdezésed végére még szükség van WHERE-re, hogy csak azok a rekordok maradjanak a listádban, ahol a munkás teljes munkaidejébe beleesik-e a checking_time.
Vmi ilyesmi kell tehát a lekérdezésed végére:
WHERE teljes_munkaido_start < checking_time AND teljes_munkaido_end > checking_time
Ha pedig ezzel is kész vagy, egy olyan listát kapsz, amiben csak azok a munkások jelennek meg, akiknek a munkaidejére esik a checking_time. A munkásokhoz annyi rekord fog tartozni, ahány munkájuk van. Ha ezekből a munkákból akár csak egynél is 'x' szerepel a segédoszlopban, akkor a munkás foglalt.
-
#1342
szmegma
aktív tag
Apollo17hu
#1341
szmegma
aktív tag
válasz
Apollo17hu
#1341
üzenetére
Na ez erdekes. Termeszetesen igazad lett, a CASE nem veszi be a FROM_UNIXTIME(workers_finishing,'%H%i')*1 egyeni elnevezeset.
Plusz syntax hiba is volt.Elso verzio: osszes oszlop = TRUE, ha megforditom a kacsacsort, akkor is TRUE!
$cheking_time = '7:30';
(CASE WHEN
'1 < ".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'Masodik verzio: osszes oszlop = TRUE, am ha megforditom a kacsacsort, akkor FALSE lesz
$cheking_time = '7:30';
(CASE WHEN
1 < ".$cheking_time."
THEN
'true'
ELSE
'false' END) AS 'oszlop'Harmadik verzio: oszlop1 = FALSE, oszlop2 = FALSE, oszlop3 = TRUE, oszlop4 = FALSE
$cheking_time = '19:30';
(CASE WHEN
FROM_UNIXTIME(workers_finishing,'%H%i')*1 > '".$cheking_time."'
AND
FROM_UNIXTIME(workers_starting,'%H%i')*1 < '".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'Mint lathato, mostmar a SELECT resz mukodik.
Az uj kod:
SELECT
booking_sheet.booking_id,
jobs_sheet.booking_id,
jobs_id,
starting_timestamp,
number,
workers_id,
workers_starting,
workers_finishing,
FROM_UNIXTIME(workers_starting,'%Y-%m-%d') AS workers_working_date,
DATE(CURDATE()+1) AS interval_start,
DATE_ADD(CURDATE()+1, INTERVAL 31 DAY) AS interval_end,
(CASE WHEN
FROM_UNIXTIME(workers_finishing,'%H%i')*1 > '".$cheking_time."'
AND
FROM_UNIXTIME(workers_starting,'%H%i')*1 < '".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'
FROM
jobs_sheet
INNER JOIN
booking_sheet
ON
jobs_sheet.booking_id=booking_sheet.booking_idA korabbi kerdesedre valaszolva, bevittem a SELECT-be azt a 31 napos idointervallumot (interval_start es interval_end), amibol szurnie kellene, hogy mely napokon van legalabb egy szabad ember 08:00-kor.
Vegulis a lenyege ennek az lenne, hogy egy arrayba gyujtse ossze ezeket a napokat.A 100 lepesbol tizet megtettunk!
A FROM utan kellene letrehozni azokat az allekerdezeseket ugye? Olvasgattam utana, de ez a "SELECT beagyazasa masik lekeresbe" tema nem konnyen emesztheto szamomra.
Meg azt sem tudom, hogy az INNER JOIN kapcsolat jo ide? Olvastam LEFT, RIGHT, FULL, NATURAL es INNER tipusokrol, de nem tudom, mikor melyik ajanlott.
Esetleg elobb a WHERE utasitasokat kellene meghatarozni?Koszonom.
-
#1341
Apollo17hu
őstag
szmegma
#1340
Apollo17hu
őstag
válasz
szmegma
#1340
üzenetére
A MySQL szintaxist nem ismerem, meg kéne próbálni, hogy a CASE WHEN-be először csak az egyik feltételt adod meg, és megnézni, hogy úgy kapsz-e TRUE értékeket. Ha nem, akkor valószínűleg nem tudja összehasonlítani a két időértéket, tehát az egyik valószínűleg nem time típusú változó.
Nekem az a furcsa, hogy a workers_start_hour -t és a workers_start_end -et ugyanebben a lekérdezésben generálod. Lehet, hogy ezek a CASE WHEN -ben még nem léteznek, ezért nem is tud velük mit kezdeni. Esetleg e kettő helyett beírhatnád a fölöttük lévő képleteket [FROM_UNIXTIME(workers_starting,'%H%i')*1 és FROM_UNIXTIME(workers_finishing,'%H%i')*1].
-
#1340
szmegma
aktív tag
Apollo17hu
#1339
szmegma
aktív tag
válasz
Apollo17hu
#1339
üzenetére
Nagy szenvedessel eddig jutottam a koddal:
$cheking_time = '7:30';
$info_get = "
SELECT
jobs_id,
starting_datetime,
number,
workers_id,
FROM_UNIXTIME(workers_starting,'%H%i')*1 AS workers_start_hour,
FROM_UNIXTIME(workers_finishing,'%H%i')*1 AS workers_finish_hour,
FROM_UNIXTIME(workers_starting,'%Y-%m-%d') AS workers_working_date,
DATE(CURDATE()+1) AS interval_start,
DATE_ADD(CURDATE()+1, INTERVAL 31 DAY) AS interval_end,
(CASE WHEN
'workers_start_hour < ".$cheking_time."' AND 'workers_finish_hour > ".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'
FROM
booking_sheet
INNER JOIN
jobs_sheet
ON
booking_sheet.booking_id=jobs_sheet.booking_id
";Viszont a segedoszlop nem mukodik. Mindenre "false"-t dob. Pedig a negy bejegyzett mukak kozul egyik igaz a kriteriumra. Nem tudtam rajonni miert.
A FROM utani resz pedig meg ennyire sem ment.
Eddig legalabb jo uton halodok?Koszonom.
-
#1339
Apollo17hu
őstag
szmegma
#1338
Apollo17hu
őstag
válasz
szmegma
#1338
üzenetére
MySQL-t nem vágom, de mezei SQL-ben vhogy így nézne ki:
SELECT munkás
,munkaidő_start
,munkaidő_end
,foglalt_start
,foglalt_end
,CASE
WHEN foglalt_start < vizsgált_időpont AND foglalt_end > vizsgált_időpont THEN
'x'
END AS segédoszlop
FROM [táblák]
WHERE [táblák kötése]
AND munkaidő_start < vizsgált_időpont
AND munkaidő_end > vizsgált_időpontSegédoszlop -ban 'x'-szel jelölöd, ha a munkás a vizsgált_időpont -ban foglalt.
A kód végén lévő két feltétel pedig csak azokat a munkásokat szűri, akiknek a munkaidejére esik a vizsgált_időpont.Az így kapott listában meg kell nézned, hogy van-e olyan munkás, akinél a segédoszlop értéke minden esetben NULL (vagyis egyik meglévő melója sem akadna a vizsgált_időpont -tal). Ehhez a fenti kódot allekérdezésbe kell majd rakni, és analitikus függvényt kell használni rá.
-
#1338
szmegma
aktív tag
Apollo17hu
#1337
szmegma
aktív tag
válasz
Apollo17hu
#1337
üzenetére
"Ha tényleg ennyire 0-ról indulsz, akkor ez nagyon necces."
Sajnos ez igaz, de konnyen tanulok es akarok is tanulni. Olvasgatom a SQL lekerdezesek foldi halandoknak 2009 c. konyvet es mar sok ujdonsagot tudtam meg.
Pl., az a NATURAL JOIN is onnan szarmazik, ami annyit tesz, a ket osszekapcsolando tablaban, ugyeber minimum egy mezo nevenek meg kell egyezni mindket tablaban. Itt jon a kepbe a natural join, ha CSAK egy mezo neve egyezik meg es pont az amelyiken at vezerelni akarjuk a lekerdezest, akkor lehet hasznalni a natural join-t."A "munkás, munkaidő_start, munkaidő_end, foglalt_start, foglalt_end" listában minden sorra meghatároznám (segédoszloppal), hogy az adott sorban lehetséges-e a kívánt munkát (időpont alapján) végezni (IF, AND és OR megfelelő kombinációjával). Ezután munkások munkanapjaiként csoportokat készítenék analitikus függvénnyel, ami megmutatná, hogy adott munkás adott munkanapján van-e ütközés (az előbb létrehozott segédoszlop). Ahol nincs ütközés, azt a munkást, és azt a napot adná vissza az eredmény"
Sajnos ez igy nekem tul magas, nem tom mi az a segedoszlop. Megprobalok hetvegen melyebben utana olvasni de igy az elso kereses a google-vel, nem eredmenyezett kielegito talalatot.
Koszonom.
-
#1337
Apollo17hu
őstag
szmegma
#1327
Apollo17hu
őstag
válasz
szmegma
#1327
üzenetére
Hát, ez sokkal bonyolultabb (legalábbis azon az úton, ahogy elindultunk), mint gondoltam.
A "munkás, munkaidő_start, munkaidő_end, foglalt_start, foglalt_end" listában minden sorra meghatároznám (segédoszloppal), hogy az adott sorban lehetséges-e a kívánt munkát (időpont alapján) végezni (IF, AND és OR megfelelő kombinációjával). Ezután munkások munkanapjaiként csoportokat készítenék analitikus függvénnyel, ami megmutatná, hogy adott munkás adott munkanapján van-e ütközés (az előbb létrehozott segédoszlop). Ahol nincs ütközés, azt a munkást, és azt a napot adná vissza az eredmény...
De néztem, hogy natural join-t használtál. (Eddig nem is hallottam róla.) Ha tényleg ennyire 0-ról indulsz, akkor ez nagyon necces. Ha valahogy össze is tudnánk rakni a modellt, lehet, hogy baromi lassan futna a lekérdezés, optimalizálásban pedig nem vagyok jártas...
-
xeqe
csendes tag
Vagy várj, valamit elnéztem. Igazából az Osszes és a below72hours alapján nem lehet kiszámolni az above72hours értékét, hiszen utóbbi két érték esetében azok a sorok számítanak ahol valami szigorúan kisebb, illetve nagyobb, mint 72. Emiatt (below72hours + above72hours) nem feltétlen egyenlő az Osszes értékével.
Tehát egyik helyen meg kellene engedni az egyenlőséget ahhoz, hogy igaz legyen:
below72hours + above72hours = Osszes. -
xeqe
csendes tag
Amennyire én tudom, csak így lehet megoldani:
SELECT
date,
Osszes,
below72hours,
Osszes - below72hours
FROM (
SELECT
date,
COUNT(*) as Osszes,
COUNT(IF(valami < 72,valami,null)) as below72hours
FROM TABLE
GROUP BY date) as temp;És ez így még ocsmányabb, mint a te megoldásod. Amúgy a teljesítmény miatt nem kell aggódnod - ebben az esetben legalábbis. Az adatbázismotor erősen optimalizálja a lekérdezést, szóval valószínűleg az általad összehozott lekérdezés is úgy fog lefutni, hogy amint megvan az Osszes és a below72hours, egy kivonással kiszámolja a hiányzó értéket.
-
#1333
Jim-Y
veterán
fordfairlane
#1332
Jim-Y
veterán
válasz
fordfairlane
#1332
üzenetére
Igazából csak érdekelt, hogy meg lehet-e oldani egy queryben
-
Jim-Y
veterán
Végül nagyjából így csináltam meg
SELECT
date,
COUNT(*) as Osszes,
COUNT(IF(valami < 72,valami,null)) as below72hours,
COUNT(IF(valami > 72,valami,null)) as above72hours
FROM TABLE
GROUP BY date;biztos nem a legszebb, de működik. Az eredeti kérdés arra irányult volna, hogy ha az above72hours-ot csak az Osszes és below72hours alapján akartam volna számolni ebben az egy queryben, akkor azt hogy kellett volna.
-
Jim-Y
veterán
Sziasztok, nem lehet olyat csinálni MySQL-ben, hogy van egy selectem, számol egy count(*)-ot valamin, illetve egy filterezett értéket.
Tehát a query eredményében lesz egy count(*) mondjuk 50, és egy filterezett oszlop, ami ugye < mint a count, legyen ez mondjuk 30.
Én az resultsetben szeretnék egy olyan oszlopot, ahol ezek különbsége is látszik, tehát COUNT(*) - Filtered.
Ezt úgy próbáltam, hogy felvettem egy akármilyen mezőt a selectben, pl 'good', majd a HAVING után próbáltam ennek értékül adni a fenti kivonás eredményét.Jó, noob kérdés tudom
-
#1327
szmegma
aktív tag
Apollo17hu
#1326
szmegma
aktív tag
válasz
Apollo17hu
#1326
üzenetére
Az elso bekezdesed elso fele kesz van. Pont en is igy talaltam ki tegnap melo kozben, hazajottem es meg is csinaltam.
A masodik fele, a lekerdezes, mar nehezebb, mivel csak tablakat tudok osszekapcsolni, mezoket nem tudom, hogy kell.Jelenleg itt tartok, ezzel megkapok minden infot amire szuksegem van, csak nem tudom, hogyan tovabb:
SELECT jobs_id,starting_datetime,number,workers_id,workers_starting,workers_finishing,regularity FROM booking_sheet NATURAL JOIN jobs_sheetSzoval megkapom az osszes munkas beosztasat az ID-vel egyutt, hogy mettol-meddig nem er ra, mivel dolgozik, ezutan, hogyan kell lekerdezni, hogy mondjuk az osszes munkas kozul van-e legalabb egy olyan, aki az elkovetkezendo 1 honapi datumokon raer, vagyis nem dolgozik 08:00-kor es csak azokat a datumokat listazza ki?
Jelenleg igy nez ki a jobs_sheet adatbazis:
CREATE TABLE IF NOT EXISTS `jobs_sheet` (
`jobs_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`booking_id` int(10) unsigned NOT NULL,
`workers_id` int(10) unsigned NOT NULL,
`workers_starting` datetime NOT NULL,
`workers_finishing` datetime NOT NULL,
PRIMARY KEY (`jobs_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5 ;
INSERT INTO `jobs_sheet` (`jobs_id`, `booking_id`, `workers_id`, `workers_starting`, `workers_finishing`) VALUES
(1, 1, 1, '2013-01-15 07:30:00', '2013-01-15 11:30:00'),
(2, 2, 2, '2013-02-11 11:30:00', '2013-02-11 14:30:00'),
(3, 3, 1, '2013-04-05 05:30:00', '2013-04-05 11:30:00'),
(4, 4, 2, '2013-04-25 09:30:00', '2013-04-25 18:30:00');A masodik bekezdesedet, sztem hagyjuk, eloszor mukodjon ez elobbi es utana lehet gondolkodni, hogyan kellene modositani, hogy az ismetlodeseket is figyelembe vegye.
Koszonom a segitsegedet. -
#1326
Apollo17hu
őstag
szmegma
#1321
Apollo17hu
őstag
válasz
szmegma
#1321
üzenetére
tisztább valamivel...
Én talán úgy csinálnám, hogy minden munkáshoz meghatároznám a szabad idő-intervallumokat (a +/-1 óra korrekcióval). Ez start_date és end_date párokat jelentene. Ezeket összesíteném (UNION?), majd erre az összesített halmazra futtatnám le a keresést, ami abból állna, hogy a kiválasztott időpont beleesik-e valamelyik intervallumba vagy sem. Ha igen, akkor nincs szabad időpont, ha nem (NULL), akkor van.
Az ismétlődéssel gondban vagyok. Azt valahogy úgy lehetne beépíteni, hogy az előre vizsgált pl. 1 hónapot le kell osztani azoknak a napoknak a számával, ami két ismétlés között eltelik, majd a hányadost kell felhasználni, de nem látom, hogy lehetne beépíteni a modellbe.
-
#1325
biker
nagyúr
Sk8erPeter
#1324
biker
nagyúr
válasz
Sk8erPeter
#1324
üzenetére
5385 sor érintett. ( a lekérdezés 0.0782 másodpercig tartott )
UPDATE users SET nev = LTRIM(nev); egész pontosan... -
#1324
Sk8erPeter
nagyúr
biker
#1322
Sk8erPeter
nagyúr
Ahogy előttem már martonx említette:
http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_ltrim
mysql> SELECT LTRIM(' barbar');
-> 'barbar' -
biker
nagyúr
heeeelp
van egy 6000 nevet tartalmazó tábla.
ebből 5400 importkor rosszul került be, mert szóközzel kezdődik
nem [kovács béla] hanem [ kovács béla]
persze innentől borul a név szerinti rendezés (az új neveket már helyesen viszik fel)Hogyan lehet az első, és csak az első szóközt kiherélni paranccsal, mert félek, a kovács és a béla közti szóközt is cserélné
előre is köszi
-
#1321
szmegma
aktív tag
Apollo17hu
#1320
szmegma
aktív tag
válasz
Apollo17hu
#1320
üzenetére
Termeszetesen tobb mezo van, csak a lenyegeseket irtam be.
A datumokat egy php funkcio generalja, mindig az aktualis nap es az azt koveto 30 nap datumait listazza ki a selectbe.
A szoveges leiras passzol, mivel a 10 karakteru szamok (1358236800) timestamp ertekek, ezek taroljak a full idot: 2013-01-15 08:00:00
Az elozo irasomat megprobalom leegyszerusiteni:Egy selectben levo ora erteket kivalasztva (pl. 08:00), fusson vegig a munkasok adatain, hogy 8 orakor melyik datumokon (maximum 30 napra elore) van legalabb egy szabad ember?
Elso variacio (hasra utott ertekek alapjan):
Ha 2013-08-08 napjan 6 orakor az elso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 9 orakor a masodik munkas dolgozik es 11 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 8 orakor az utolso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Vegignezte a munkasokat, hogy ki-mikor dolgozik es a 2013-08-08 datum nem szabad, mivel mindenki foglalt a kivalasztott oraban (08:00).
Igaz, hogy a masodik munkas nem dolgozik 8 orakor, hanem 9-kor kezd, de 1 orat kell szamolni mindket iranyba, amit foglaltnak veszunk.Masodik variacio (hasra utott ertekek alapjan):
Ha 2013-08-08 napjan 6 orakor az elso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 10 orakor a masodik munkas dolgozik es 11 orakor fejezi be, akkor o szabad.
Ha 2013-08-08 napjan 8 orakor az utolso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Vegignezte a munkasokat, hogy ki-mikor dolgozik es a 2013-08-08 datum szabad, mivel a masodik munkas nem dolgozik a kivalasztott oraban (08:00).Igy mar tisztabb?
Elarulom, hogy az adatbazis tablak mezoi meg nem veglegesek; folyamatosan szerkesztem, ha mashogy jobbnak latom.
Pl., ezt a +- 1orat is amit az elso variacioban emlitettem, vhogy mashogy fogom megoldani, valoszinuleg eltavolitom a finishing_datetime mezot, mivel felesleges, hiszen a kezdo idopontbol egy orat le kell vonni, ehhez a munka hosszat hozzaadni + meg 1 orat es mar meg is van egy munkas napi idolefedettsege.Koszonom.
-
#1320
Apollo17hu
őstag
szmegma
#1317
Apollo17hu
őstag
válasz
szmegma
#1317
üzenetére
Megpróbáltam elgondolkodni rajta, de már ott elakadtam, hogy a szöveges leírás hogy passzol a példaértékekhez. A dátumokat honnan veszed? Bele van passzintva az azonosítókba? Ha igen, milyen szabály alapján? Szerintem több mezőben kellene tárolni az adatokat, de lehet, hogy csak én nem látom át...
-
martonx
veterán
válasz
szmegma
#1317
üzenetére
Ez a szokásos, hogy kell a select * from táblát lefuttatni php-ben kérdések szintjét meghaladja
![;]](//cdn.rios.hu/dl/s/v1.gif)
Két lehetőséged van:
1. használod az sqlfiddle-t, és létrehozod a táblákat, példa adatokkal, aztán várod a jószerencsét, hogy hátha valaki megszán, és helyetted beleteszi azt a pár órányi sql szakértői munkát.
2. eleve pénzt jánlasz ezért, és akkor biztosan lesz aki beleteszi azt a pár órányi sql szakértői munkát. -
szmegma
aktív tag
Egy MySql gurura lenne szuksegem az alabbi problemammal kapcsolatban.
Van 3 tabla. A booking_sheet, jobs_sheet es workers_sheet.
A booking_sheet tartalmazza egy leadott megrendeles adatait:`booking_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`starting_datetime` int(10) unsigned NOT NULL,
`regularity` tinyint(2) unsigned DEFAULT NULL,
PRIMARY KEY (`booking_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 megrendeles (booking_id,starting_datetime,regularity):
1, 1358236800, 14
2, 1360584000, 7
3, 1365141600, NULLA jobs_sheet, a fonok booking_sheet altal kiosztott munka adatait tartalmazza. Beallitja a munka vegenek idopontjat es egy mukas ID-jet rendeli hozza:
`jobs_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`booking_id` int(10) unsigned NOT NULL,
`workers_id` int(10) unsigned NOT NULL,
`finishing_datetime` int(10) unsigned NOT NULL,
PRIMARY KEY (`jobs_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 ekeszitett rekord (jobs_id,booking_id,workers_id,finishing_datetime):
1, 1, 2, 1358251200
2, 2, 3, 1360594800
3, 3, 1, 1365163200A workers_sheet pedig a munkasok adatait tartalmazza:
`workers_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`workers_name` varchar(255) NOT NULL,
PRIMARY KEY (`workers_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 munkas (workers_id,workers_name):
1, Jozsi
2, Geza
3, BelaEgy megrendelo lapot keszitek, ahol orat es datumot kell kivalasztani az ugyfelnek.
Ha mondjuk kivalasztja a 08:00, akkor ugy kellene lefutnia egy keresnek, hogy 8 orakor melyik napon van legalabb egy szabad ember es azokat a napokat adja vissza a datumvalasztoba.
Csak, hogy ne legyen ilyen egyszeru, mint latjatok van egy regularity mezo, mely azt adja meg, hogy az elso kivant munkanap utan, hany nap mulva kell ujra az adott idopontban menni dolgozni.A fenti peldak szoveges formaban:
Az 1. szamu melot 2013-01-15 08:00:00-kor Geza kezdi, melynek befejezese 2013-01-15 12:00:00-kor es 14 naponkent ismetlodik, tehat 2013-01-29 08:00:00-kor ujra kezdi stb.
A 2. szamu melot 2013-02-11 12:00:00-kor Bela kezdi, melynek befejezese 2013-02-11 15:00:00-kor es 7 naponkent ismetlodik, tehat 2013-02-18 12:00:00-kor ujra kezdi stb.
A 3. szamu melot 2013-04-05 06:00:00-kor Jozsi kezdi, melynek befejezese 2013-04-05 12:00:00-kor es nem ismetlodik.Na mar most, ha vki a megrendelo lapon kivalasztja a 08:00, akkor lathato, hogy minden datum szabad esmegjelenitheto, hiszen legalabb egy munkas szabad barmelyik napon 8 orakor.
Szamomre ez a kerdes igencsak meghaladja a tudasom, pedig ezt a hetveget MySql tanulassal toltottem. Sok mindent tanultam, de ezt nem tudom megoldani egyedul.
Ha vki tudna segiteni, halas lennek.Koszonom.
-
#1316
Brown ügynök
senior tag
martonx
#1315
Brown ügynök
senior tag
válasz
martonx
#1315
üzenetére
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Akkor ez azt jelenti, ha egy adatbázisban megfelelőn használjuk az idegen kulcsokat az nagy mértékben hozzájárul a teljesítmény növeléséhez?
Ahogy elnéztem egyébként, inkább az indexek hiánya lehet a ludas, mint a túl nagy száma. Úgy látom, ez egy összetett kérdés... Egyébként az program szinten nem akarok nagyon belenyúlni, mert elég mosott a kód. Igyekszem adatbázis oldalról javítani (ha lehet). Az igazi megoldást persze egy egészséges újraírás jelentené (és nem csak a lassú lekérdezések miatt).
-
#1315
martonx
veterán
Brown ügynök
#1314
martonx
veterán
válasz
Brown ügynök
#1314
üzenetére
Ez sok mindentől függ. Mennyire komplex például az index, mennyi indexed van a táblán stb...? Ha komplex, és sok az index akkor az írást lassítja.
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Az írás tűnik lassúnak vagy az olvasás? Mert ha az olvasás a lassú, akkor viszont mindenképpen kell az index, különben nélküle meg megállna az élet. Még ha ez miatt némileg lassul is az írás.
Szóval igazán jó válasz nem biztos, hogy van a kérdésedre.
Kérdés az is, hogy mit értesz azonos mennyiségű írás, olvasásnak? Naponta 100 sort beírsz, és 100 sort ki is olvasol? Vagy hogy naponta 100-szor olvas valamit a táblából, és 100-szor ír valamit a táblába a db motor? Ez esetben a valamit az érdekes, hogy 100-szor beír 1 sort, vagy 100-szor beír 2000 sort?
Ez esetben pl. az írási stratégiáján a programnak érdemes lehet változtatni. -
#1314
Brown ügynök
senior tag
martonx
#1313
Brown ügynök
senior tag
-
#1313
martonx
veterán
Brown ügynök
#1312
martonx
veterán
válasz
Brown ügynök
#1312
üzenetére
Azt azért tartsd észben, hogy a MySQL optimalizációnál erősen meglőnek, ha eleve nem jól beállítva telepítik fel.
Úgyhogy vagy neked kell egyben a rendszergazdának, DBA-nak is lenned, vagy utólag simán előfordulhat az az eset, hogy marhára nem fogsz tudni mit optimalizálni, mert a telepítéskor elcseszett setup miatt egyszerűen mindeféle diagnosztizáló funkció le van tiltva rajta.
És ezeken utólag nagyon nem szeretnek a rendszergazdák változtatni. -
#1312
Brown ügynök
senior tag
Peter Kiss
#1310
Brown ügynök
senior tag
válasz
Peter Kiss
#1310
üzenetére
Ilyen lekérdezéssel szerencsére én még nem találkoztam.
@martonx: Átnéztem a táblákat és nincs olyan nagy vegyítés a motoroknál.
Egyébként októberben költözik a cucc modernebb vasra, addig nézek valami okosságot a MySQL optimalizációjáról szóló fejezetében.
-
#1310
Peter Kiss
őstag
Brown ügynök
#1306
Peter Kiss
őstag
válasz
Brown ügynök
#1306
üzenetére
Ha már optimalizálás, ma találkoztam egy problémával, egy drop down list-et, amiben 2000 elem volt kb. 8000 SQL lekérdezéssel (mindegyikhez volt 4) töltött fel egy hülyegyerek. Újraírtam, hogy lejöjjön egyben.
-
martonx
veterán
Híjnye, jól látom, hogy a MySQL-lel hivatalosan nem lehet %-ot megadni a Limitnek? Pedig ez PostgreSQL-ben, MS SQL-ben (gondolom Oracle-ben is) támogatott.
Mindegy itt egy kerülő megoldás:SELECT*
FROM (
SELECT list.*, @counter := @counter +1 AS counter
FROM (select @counter:=0) AS initvar, list
ORDER BY value DESC
) AS X
where counter <= (10/100 * @counter);
ORDER BY value DESC -
Jim-Y
veterán
Sziasztok. Adott a következő szituáció:
van egy tábla, ahol vannak bizonyos tulajdonságú rekordjaim, mondjuk legyen egy NUM nevű oszlop.
Szeretnék ezen csinálni egy olyan lekérdezést, hogy minden olyan sort szedjen ki, ahol NUM = 1, rendezze egy másik oszlop szerinti csökkenő sorrendbe, ÉS! (itt a probléma) csak az első 10%-ot listázza.Pl NUM = 1 sorból van 2000 db, ezeket rendezem egy másik mező szerint csökkenőbe, de ezekből csak 2000*0.1 darabot szeretnék listázni.
Ott akadtam el, hogy ha a LIMIT után egy változót teszek, akkor szintaktikai hibát dob. Hogy lehetne ezt megoldani id-kel való lavírozás nélkül? üdv
-
#1307
martonx
veterán
Brown ügynök
#1306
martonx
veterán
válasz
Brown ügynök
#1306
üzenetére
Mondjuk jobban utána gondolva az e pont azért okozhat némi teljesítmény problémát (MySQL sosem volt sebesség bajnok, pláne nem a korai verziói), illetve bizonyos esetekben a d pont is bezavarhat, bár ezt nem tartom túl valószínűnek.
-
#1306
Brown ügynök
senior tag
Brown ügynök
senior tag
@Athlon64+, @martonx: Akkor jobban elmerülök az indexelésben. Ez az a pont amin most könnyen javíthatok. (Egyébként nem tudom milyen vas szolgálja ki a rendszert, ennek majd utánaérdeklődöm.)
-
#1305
martonx
veterán
Peter Kiss
#1304
martonx
veterán
válasz
Peter Kiss
#1304
üzenetére
Az f pont biztos nem, a g-t, h-t nem részletezted.
-
#1304
Peter Kiss
őstag
Brown ügynök
#1303
Peter Kiss
őstag
válasz
Brown ügynök
#1303
üzenetére
Elsőre szar lekérdezések (és indexek), illetve rosszul beállított szerver. Az a baj, hogy ezt már tényleg látni kellene.
-
#1303
Brown ügynök
senior tag
Brown ügynök
senior tag
Adott egy adatbázis kb. 200 táblával, melyet egyszerre maximum 10-15 használnak. Az itt felsoroltak közül melyek okozhatják a "slow query"-ket (illetve, hogy a rendszer többször érezhetően kegyelemért könyörög)?
a) Az egyik tábla 23 millió rekordot tartalmaz (a többi, 2 kivételével általában pár tízezret)
b) Optimalizálatlan lekérdezések
c) Adatbázis tervezési hibák
d) InnoDB, MyIsam vegyesen
e) Elavult MySQL verzió (5.1.49)
f) A MySQL ennyit bír
g) Vashiány
h) C-vitamin hiány
-
#1302
nova001
senior tag
Sk8erPeter
#1301
nova001
senior tag
válasz
Sk8erPeter
#1301
üzenetére
köszi tényleg...megtaláltam
csak nem biztos, hogy előrevisz.) Ezt nem sértésként mondtam, ne is vedd kérlek annak! 
Üdítőbb ezeknél egy érdemi kérdésről témázás, igaz, Apollo17hu lényegében másnak oldja meg a munkáját tök ingyen, mindenesetre a kitartásáért jár neki a virtuális sör. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- NVIDIA® driverek topikja
- Gyúrósok ide!
- Autószerelők, autószerelés
- Vizsgálat indult, a Meta chatbot gyerekekkel folytatott romantikus beszélgetést
- Bambu Lab 3D nyomtatók
- Autós topik
- Sokrétű segédkijelzővel gyarapodott a Corsair portfóliója
- Azonnali fotós kérdések órája
- Fotók, videók mobillal
- Fogyjunk le!
- További aktív témák...
- Eladó Ryzen 7 7700X, 7800 XT, 1Tb M.2, 750W, 32Gb DDR5 AM5 gamer pc!
- MINI PC HP PRODESK 600 G2 G3 G4 G5 i3 és i5 6-9. gen gar. Budapest MPL Foxpost
- AZTA! HP EliteBook 840 G8 Fémházas Laptop Ultrabook 14" -60% i7-1185G7 16/512 FHD IPS Iris Xe
- Asus P8H61-M LX R2.0 LGA 1155 alaplap, + Quad Core i5-2500 CPU
- LEGO Technic - Bugatti Chiron (42083)
- Surface Laptop 7 Business edition - Intel Core ultra 5 236V energiahatékonyabb az intelnél! -olvass
- GYÁRI TÖLTŐK DELL LENOVO HP FUJITSU TOSHIBA Macbook---------- Budapest,/MPL/Foxpost
- GYÖNYÖRŰ iPhone 12 64GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3302
- Szinte új! 3 Hónapos! Playstation 5 Slim Disc (Lemezes) Kiadás! Garancia: 2027.05.15
- Asus 14 Zenbook UX425E FHD IPS i7-1165G7 4.7Ghz 16GB 512GB SSD Intel Iris XE Graphics Win11 Garancia
Állásajánlatok
Cég: FOTC
Város: Budapest