Új hozzászólás Aktív témák
-
rum-cajsz
őstag
nem tudom pontosan mit szeretnél, de megoldás lehet a date_trunc és a between is
date_trunc(text, timestamp)
pl:
date_trunc('day', timestamp '2001-02-16 20:38:40') ----> 2001-02-16 00:00:00Az összes dátum függvényt itt találod:
Postgresql KK[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Sajnos nem tudom hogy lehet összehasonlítani MYSQL adatbázis struktúrákat, de ha a struktúrák egyeznek, de nem azonos a joomla verziód, én nem próbálkoznék az adatbázis felülírásával, mert még ha el is indul az oldal kérdés, hogy nem írtál-e felül valamilyen rendszerbeállítást, ami az adatbázison belül tárolódik.
Én inkább egy konverzióval próbálkoznék a helyedben.
Megkeresni melyik táblában tárolja a cikkeidet, és azokat insertel direkben beletenni a jelenlegi adatbázisba. (persze itt is figyelni kell az integritás megőrzésére, például az egyedi kulcsokra)=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz lordring #565 üzenetére
A selectben kell egy group by, a számított mezőkre pedig csoportosító fv.
Ha jól értem ez kellene:SELECT
T1.[CardCode], sum(T0.[Quantity]), sum(T0.[LineTotal])
FROM INV1 T0
INNER JOIN OITM T1 ON T0.ItemCode = T1.ItemCode
WHERE T0.[DocDate] >=[%1] and T0.[DocDate] <= [%2]
group by T1.[CardCode]=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
A group by-t nem arra az oszlopra kell, amire a függvényt használod, hanem amire csoportosítani akarsz:
SELECT COUNT(s.instructor_id), i.first_name, i.last_name
INTO v_course_numb, v_first_name, v_last_name
FROM section s, instructor i
WHERE s.instructor_id = v_instructor_id
GROUP BY i.first_name, i.last_name;Nem tudom melyik adatbázis kezelőn használod, de jó, ha tudod, ha a count-on belül használsz oszlopnevet, akkor annak "null" értéke esetén elképzelhető, hogy nem összegzi az a sort. Ha az összes sort akarod számolni pontosabb ez a kód:
SELECT COUNT(*), i.first_name, i.last_name
INTO v_course_numb, v_first_name, v_last_name
FROM section s, instructor i
WHERE s.instructor_id = v_instructor_id
GROUP BY i.first_name, i.last_name;Ha jól emlékszem Oracle-nél ez mindegy.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz WonderCSabo #747 üzenetére
Igazad van, szemantikailag nem néztem, csak a szintaktikát.
Most látom, hogy a két táblát nem is kapcsolta össze, így ez hibás eredményt fog adni.
Én így csinálnám.SELECT s.instructor_id,i.first_name, i.last_name,COUNT(*)
INTO v_dummy,v_first_name, v_last_name,v_course_numb
FROM section s, instructor i
WHERE s.instructor_id = i.instructor_id
and s.instructor_id=v_instructor_id
GROUP BY s.instructor_id,i.first_name, i.last_name;Mondjuk könnyebb lenne, ha tudnánk mi a feladat, és a két tábla szerkezete...
[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Össze kell kapcsolni a két táblát.
Az oracle féle lusta szintaxis azt hiszem működik mssql alatt is:
select x.megyenev,y.szemelynev
from szemely y,megye x
where y.megyeid=x.megyeid;ha nem, akkor a join parancs kell neked,
[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
alselect: amikor sok táblát kell összekapcsolni, akkor szoktam használni (oracle), és az optimalizáló meg szokta hálálni. 1-2 órás futás helyett 10-20 perces eredmény.
temp tábla: A nem használat szerintem is hülyeség. Vagy mit javasolnak helyette? Esetleg memóriában tárolt tömböket?
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Ez a hibaüzenet kettőt jelenthet:
1. a tábla nem létezik a teamdestiny555 felhasználónál
2. nincs lekérdezés joga a létező táblára a felhasználónak.Hogy ez a telepítéskori hibákkal összefügg-e, azt neked kellene tudnod, mert ennyiből nem fogjuk kitalálni.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz rum-cajsz #887 üzenetére
A gyárban megtaláltam neked, ezzel lehet lekérdezni az aktuális selectet:
select sql_text from v$sqltext_with_newlines
where address = hextoraw(:sql_address)
and hash_value = :sql_hash_value
order by pieceAz :sql_address és a :sql_hash_value változókat pedig a v$session táblából tudod lekérdezni.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Octopus21 #907 üzenetére
Szia!
Szerintem ha ennyire nem tudod miről van szó, akkor ideje lenne talán egy könyvet elolvasni.
A fórumok nem arra valóak, hogy megtanulják helyetted a cuccot.
Ha van konkrét kérdésed, akkor arra biztos szívesen válaszol valaki, de most kb azt kéred, hogy magyarázzuk el neked, amit eddig magyaráztak neked a tanfolyamon.=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz wolandino #964 üzenetére
Ha ennyire fontos ez az évszám, én biztos ellátnám tranzakciós adatokkal. A minimum, hogy ki, mikor változtatta. A legjobb, ha van érvényességi ideje a soroknak, és csak az az érvényes év, ahol az érvényesség dátuma üres.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Oracleben van lehetőség a Materializált Nézetekre, amivel valóban lehet gyorsítani a selectedet, de ezt körültekintően érdemes használni.
De a legfőbb kérdés, hogy mire akarod használni az adott selectet. A hálózati forgalom pl. minimalizálható, ha nézetet használsz, ám ha ezt a lekérdezést egy sql*plusban adod ki, akkor nem lesz különbség a két (select contra view) között.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Nem írtad az adatbázist! Oracle-ben pl. az ALL_IND_COLUMNS nézetből lekérdezheted:
select
INDEX_NAME,
LPAD(TABLE_NAME,17) TABLE_NAME,
LPAD(COLUMN_NAME,15) COLUMN_NAME,
LPAD(COLUMN_POSITION,5) COLUMN_POSITION
from ALL_IND_COLUMNS
WHERE TABLE_NAME = upper('&tablename')
order by INDEX_NAME,COLUMN_POSITION;=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz InfiniteReality #1042 üzenetére
Csak annyi hiányzik, hogy a lekérdezésed most évenként jön fel, szóval kívülre kell még egy group by.
Vagy csinálsz egy nézetet a szétbontott táblákra, és akkor elég egy group by a nézetre.pl:
SELECT jatekos, sum(pont) FROM
(
SELECT jatekos, pont FROM jateklista2005 WHERE pont >= '1'
UNION
SELECT jatekos, pont FROM jateklista2006 WHERE pont >= '1'
)
GROUP BY jatekos
ORDER BY 2 DESC LIMIT 50[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Csak azokat a mezőket érdemes indexelni, amire keresni akarsz.
Ha a kereséseid több mezőre egyidejűleg történnek, akkor érdemes több mezőre összetett indexet tenni, sőt ha valamilyen függvényt használsz, akkor függvény alapú indexet érdemes használni.
Minél több indexed van, annál lassabb lesz az insert és a delete, mert a sorok felvételével és törlésével egyidejűleg az indexsorok létrehozása is létrejön, törlődik.
Ha többféle lekérdezés is történik a táblán, akkor érdemes lehet több oszlopra is indexet tenni a lekérdezések függvényében.
Összetett index esetén csak akkor fog működni az index alapú keresés, ha az első oszlop legalább benne van a feltételek között.És azért van ilyen neved (SYSxxxxx), mert nem nevezted el az indexet létrehozáskor (pl. primary key definiálásakor), ilyenkor egy rendszer által generált néven jön létre az index.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz WolfLenny #1138 üzenetére
Nekem foleg oracle-vel vannam tapasztalataim, de ugy sejtem a mysql sem lehet nagyon mas.
El kell dontened, hogy mi a feladatok prioritasa es az alapjan kell dontened.
Akkor eri meg a sok tabla, ha nagyom sok adat (tobb szaz millio) kerul bele adott idoitervallumon belul, es a regi adatokat folyamatosan ki akarod torolni.
Szinte barmelyik SQL adatbazis elboldogul a 100-500 millio sorokkal, ha jol van idexelve, van eleg memoriad, es eleg gyors vinyok vannak alatta.
A havi bontasokkal csak szivatod magad szerintem.
Egyreszt gondoskodni kell arrol, hogy letrejojjon az uj tabla. masreszt folyamatosan karban kell tartanod a viewt, harmadreszt az union miatt sokkal lassab lesz a lekerdezesed, mintha egy tablaben lenne az adat.
VISZONT.
Ha egy tablaban van az adat, es torolni akarsz belole idonkent sok adatot (havonta partizmillio sort), akkor a torles elegge megfoghatja a tabla elereset, es ilyenkor celszeru a tabla bontasa.Remelem tudtam segiteni. kerdezz batran.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Speeedfire #1152 üzenetére
vagy írsz egy függvényt, vagy egy másik táblában definiálod a kívánt sorrendet.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
-
rum-cajsz
őstag
válasz lazlora #1202 üzenetére
Itt gyakorolhatsz többféle adatbázisban is alapdolgokat: http://sqlzoo.net/
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Sk8erPeter #1213 üzenetére
A dátumformátumot beállíthatod a kliens paraméterei között (mármint az oprendszerben), nem kell állandóan kiadni a lenti parancsot.
[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Hihetetlenek vagytok, hogy ebből a lent megadott selectből ki tudtátok találni, hogy mit akar kérdezni az illető....
Nekem nem ment, pedig elolvastam kétszer is, hátha figyelmetlen voltam.[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Fecogame #1232 üzenetére
elméletileg máködhet, ha a fórumokat ugyanarra az adatbázisra állítod be, de gyakorlatilag ennek a kivitelezése szerintem nagyon sok hibát/problémát fel fog vetni.
Főleg ha a két fórum beállításai nem 100%-osan ugyanazok lesznek. Mondjuk más témákat telepítesz egyikre, mint a másikra, stb....[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Fecogame #1238 üzenetére
Hát, ennek a megoldása függ attól, hogy milyen fórummotort használsz. Mert nem elég átnevezned a táblákat, hanem az összes config táblában és config fájlban is át kell állítanod az új prefixet.
Én azt próbálnám meg, hogy csinálok egy vadonatúj telepítést az új prefixekkel, és utána betölteném az új táblákba a régiek tartalmát. Ez után leellenőrizném az összes táblát, hogy van-e benne olyan config sor, amiben szerepel táblanév, mert ha igen, akkor azt is javítanám.
Csak ez után indítanám el a fórumot, és kipróbálnám, hogy jól működik-e. Ha igen, akkor mehet élesben, ha nem, akkor keresni kell valami más megoldást.A másik lehetőség, hogy a fórum motor támogatja a táblák átnevezését, akkor könnyebb dolgod van.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Yushchenko #1274 üzenetére
Legjobb tudomásom szerint az sqlplus-ban tényleg csak ezt lehet csinálni, hogy összefűzöd az oszlopokat a ";"-vel.
A sorvégi space-t tudod levágni aSET TRIMS ON
sqlplus paranccsal.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz Sk8erPeter #1292 üzenetére
"Gondolom erre a képre gondoltál: [link]. "
Haha, ez király!
[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
-
rum-cajsz
őstag
válasz Sk8erPeter #1303 üzenetére
Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda. (de látom Te is pont ezt írod alant)
Azt pedig már tényleg csak nagyon zárójelben jegyzem meg, hogy ha a dátum adatok vegyes szerkezetűek, akkor elég nagy felelőtlenség/hanyagság előfeldolgozás nélkül belehányni őket egy dátum típusú mezőbe.
De az eredeti kérdés egyébként így nézett ki:
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)Szerintem nincs olyan valós indok, ami felhozható a prepare statment ellen. (de szerintem ebben is egyetértünk)
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
egyre több az indok az access adatbázisod kidobására, miért nem használod ki?
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
-
-
rum-cajsz
őstag
válasz perempe #1431 üzenetére
jééé, tőlem tanulsz? kérdezz inkább.
Ha szenvedni akarsz, akkor az Accessben azt kell csinálnod, amit már itt korábban leírtak.
De én egy Mysql adatbázis telepítést javasolnék a gyakorláshoz, kb 1 perc.
Ez az egyik legegyszerűbb csomag, amiben mysql is van: http://www.easyphp.org/[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz lakisoft #1550 üzenetére
A verziókezelés használata önfegyelem kérdése. Nem is értem miért ne lehetne a tárolt eljárásokat verziókezelni, hiszen végül is azok is csak sima szöveges "fájlok".
A második résszel meg egyszerűen nem értek egyet. Vagy mit nevez ő a XXI. század fejlesztői eszközének?
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz martonx #1578 üzenetére
haha,
Nem tudom melyik adatbázisra gondoltál, de hivatalos Oracle oktatáson mégis elhangzott (a tapasztalt Oracle szakértő szájából), hogy szép-szép az új join szintaktika, de ha biztosra akarunk menni akkor használjuk a régi módszert....=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
válasz martonx #1585 üzenetére
Ó, én az Oracle optimalizáló fejlesztőiből bármit ki tudok nézni, annyi minden
"faszsággal"érthetetlen dologgal találkoztam már. Ebbe belefér az is, hogy a joint rosszul (értsd: nagyobb költséggel) értelmezi egyik illetve másik esetben.
De lehet, hogy csak a rosszindulat beszél belőlem, és mostanra már tényleg szép és jó az Oracle join szintaxisokkal.[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
Új hozzászólás Aktív témák
- 1.250.000 FT helyett 940.000 FT !! MacBook Pro 16" M3 Pro 12CPU / 18GPU / 18GB / 512 SSD
- RTX 2080TI ROG STRIX GAMER PC
- AKCIÓ !! M3 Chip - MacBook Pro 14" 8C CPU / 10C GPU / 8 GB/ 1 TB / Bontatlan / Magyar
- Tidradio td-h3 akkumulátor
- HP ZBook Studio x360:i7 9850H,32GB,512GB,P2000,15.6" UHD 3840x2160 TOUCH 600nit 100%AdobeRGB,HP gari