Hirdetés
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- OLED TV topic
- Milyen TV-t vegyek?
- Projektor topic
- 3D nyomtatás
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Picit gazdaságosabb és halkabb lett a PlayStation 5 Pro legfrissebb verziója
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen videókártyát?
Új hozzászólás Aktív témák
-
rum-cajsz
őstag
Nem ismerem a MariaDB lehetőségeit de én ezt úgy oldanám meg, hogy van egy function, amiben egy olyan kurzor van, ami a felolvasandó táblákon megy végig, a belseje pedig végrehajtja a lekérdezést a paraméterként kapott táblán, és egy record típusú OUT változóban gyűjti a dolgokat összegezve, alternatív megoldás, hogy egy külső táblába insertája a gyűjtött adatokatl. Ezt Postresben és Oracle-ben dinamikus query-nek hívják.
De ennek a megoldásnak elég komoly limitáció vannak és nagyon nem mindegy, hogy mennyi rekordon akarsz dolgozni. Mennyi recordot vársz eredménynek.
Ha jól olvasom, szenzorok adatait akarod összegezni, amire sokkal egyszerűbb és tartósabb megoldás a többek által javasolt triggeres módszer.
Arra is oda kell figyelni, hogy az adatbázisban ha elszaporodnak a táblák, az tud tárolási és működési kockázat lenni. Nem tudom hány szenzorról beszélünk, de mondjuk százezres nagyságrendnél az általad elképzelt bármelyik működés használhatatlan lesz. -
rum-cajsz
őstag
válasz
RedHarlow
#4208
üzenetére
ha linuxot használsz, annak van egy nagyon jó ütemezője a cron. Azzal gyakorlatilag bármilyen ütemezést be tudsz állítani. Bár az excel és a mail küldés még külön programot igénylenek.
A szkriptet kell megírnod egyedül, kell egy oracle kliens, amiben sqlplus programot tudod parancssorban használni. pl. ez minden óra 27 perckor lefut
cron bejegyzés:27 * * * * /home/user/sqlscript/napifutas.shnapifutas.sh
ScriptHome="/home/user/sqlscript"PwFile="$PasswdHome/jelszo.txt"secret=UserName/$(< $PwFile)@adatbazissqlplus -s <<EOF$secret@$ScriptHome/sajatscript.sqlEOF -
rum-cajsz
őstag
válasz
bandi0000
#4032
üzenetére
Ha jól értem a problémádat, akkor nem a dátumot/időt kell kitenni a külön táblába, hanem a vásárláshoz tartozó termékek listáját.
Tehát a te logikád szerint:
TERMÉK (termékid, terméknév, stb)
VÁSÁRLÁS (vásárlásid, eladó, vevő, dátum, fizetendő, stb)
VÁSÁRLÁSTÉTEL (id, vásárlásid,termékid, db, stb.)táblák kellenek.
-
rum-cajsz
őstag
válasz
htcwanted
#3338
üzenetére
Mivel nem csak új sort tudnak felvinni a felhasználóid, hanem már meglévő sorok adataiban is módosíthatnak mégis az a legegyszerűbb technikailag, amit Cathfaern javasolt.
Martonx kolléga megoldásával az a probléma, hogy ő feltételezi, hogy a már elmentett adatokon nem változtatnak a felhasználók. Ha ez megtörténhet, akkor neked a teljes táblákat kell összehasonlítanod mondjuk a MINUS operátorral.
De az is fontos kérdés lehet, hogy milyen adatbázisban akarod működtetni? És mekkora adatmennyiségről (hány sor) van szó?
-
rum-cajsz
őstag
Nincs semmi előre gondolkodás, programtervezés van.
Amikor összeállítod a php programodban a táblázatot a benne szereplő sql eredményéből, akkor az eredményeket linkké alakítod a táblázaton belül, és ez a link egy újabb oldalt tölt majd be aminek ez a szám a paramétere.Tényleg annyira alap php dolgot kérdezel, amit nem fogunk itt neked tudni megválaszolni terjedelmesebben, és semmi köze nincs az SQL-hez. Vagy legalábbis annyi köze van kb, mint hogy melyik szövegszerkesztőt használd a php programod írásához.
-
-
rum-cajsz
őstag
válasz
MineFox54
#3165
üzenetére
Értelek, akkor viszont nem az adatbázisban van a hiba, mert ez nálam tökéletesen működik:
CREATE TABLE tankonyv (evtol NUMBER,evig NUMBER,tantargy VARCHAR2(10));
INSERT INTO tankonyv SELECT 9,12,'Matematika' FROM dual;
SELECT * FROM tankonyv WHERE evtol<='11' AND evig>='11' AND tantargy='Matematika';
DROP TABLE tankonyv PURGE; -
-
rum-cajsz
őstag
válasz
martonx
#3035
üzenetére
Mondjuk martonx kollégának igaza van abban, hogy ha csak egy irányból érkeznek adatok (a programodból), és úgy is most tervezed az egészet, akkor a trigger helyett jobb, ha programból csinálod az insertet is.
A trigger megoldás inkább akkor lehet jó, ha több irányból (több programból, betöltésből, stb.) is érkezhetnek adatok, és nem akarod/ nem tudod ellenőrzötten az összes programodat átírni. -
rum-cajsz
őstag
válasz
Jim Tonic
#3033
üzenetére
Igen, értettem én, ezért írtam a kiegészítést alulra. Tehát a select lehet ilyen is:
SELECT new.rendszám,new.autószíne, new.autótípusa from TABLE_B where table_b.rendszem=new.rendszam;
Persze ehhez az kell, hogy a TABLE_B lekérdezés eredménye csak egy sor legyen, tehát a lekérdezésed úgy kell paraméterezni, hogy a végén egy sor legyen a lekérdezés eredménye.
-
rum-cajsz
őstag
válasz
Jim Tonic
#3031
üzenetére
Ha igazán szép megoldást akarsz, akkor készítesz egy tárolt eljárást, aminek a paramétere a vizsgálandó adat. Tartalma pedig egy insert-select Utána az after triggerben meghívod ezt a programot, amikor szükséges. De az insert-select mehet közvetlenül a trigger kódjába is. pl. az ID egy oszlopa a tábla1 tábládnak.
create trigger sajáttrigger
active after insert or update
on tábla1
as
begin
insert into tábla3 (number, name)
select number, name from tábla2 where Accepted = new.id;
endErre gondoltál?
szerk:
Ja most látom, hogy az 1-es táblából akarsz értéket tenni bele, akkor úgy kell az oszlopokra hivatkoznod, hogy new.oszlopnév ez annak a táblának az oszlopa, ahová most éppen be akarsz szúrni, vagy módosítasz. -
#2814
rum-cajsz
őstag
-=Flatline=-
#2810
rum-cajsz
őstag
válasz
-=Flatline=-
#2810
üzenetére
Ha jól értelek, akkor felhasználónként a legkorábbi helyes tipp kell, az ez (kicsit bőbeszédűen):
select kvizid,name,
DATE_FORMAT(time, '%Y-%m-%d') as Day,
min(time) as Időpont
from prohardver
where helyes=1
group by kvizid,name,DATE_FORMAT(NOW(), '%Y-%m-%d'); -
#2799
rum-cajsz
őstag
sityupityka
#2798
rum-cajsz
őstag
válasz
sityupityka
#2798
üzenetére
negyvenkettő
-
rum-cajsz
őstag
Azt most nm pont értem, hogy miért nem ad vissza sort a te példád, viszont ha visszaadna, akkor sem biztos, hogy azt kapnád, amit szeretnél, mivel a lekérdezés eredménye order by nélkül nem feltétlenül ugyanazt a sorrendet adja vissza egymás után kétszer.
Az első 3 sort így tudod szűrni:
begin
for i in (
select * INTO emp_adatok from emp where ROWNUM<4
) loop
dbms_output.put_line(i.ename);
end loop;
end; -
rum-cajsz
őstag
Erre a kérdésre ne nagyon várj komoly választ. Ha van konkrétum, abban tudunk segíteni, de két adatbázis migrációjának elvégzését csak úgy lehet megmondani, ha ismertek az adatbázisok.
Elméletileg bármit lehet, ami már bent van az adatbázisban, gyakorlatilag fel kell mérni a két adatbázis közös és eltérő pontjait, és egy áttérési tervet kell kidolgozni. Az áttérés előtt érdemes a két adatbázist helyben normalizálni, és csak ez után elvégezni az összefésülést.
Esetleg arra is van lehetőség, hogy ugyanazon a gépen több adatbázis is fut, akik nem tudnak egymásról.
-
rum-cajsz
őstag
Én szívesen segítenék, de nem értem a kérdésed sem. Tudnál készíteni egy példát az sqlfidle oldalon?
Már azt sem értem, ha ugyanazt a mezőt akarod ugyanazzal a mezővel összehasonlítani, és csak az egyik oldalon konvertálsz, akkor mit vársz? Ha konkrét értékeid vannak, akkor miért nem jó az egyenlőség helyett az IN () ?
-
rum-cajsz
őstag
válasz
#68216320
#2713
üzenetére
Openstreetmap-en nagyon sok geolokációs adat lekérdezhető, ez is. Csak azért nem ezt javasoltam elsőre, mert ennek a minősége nem feltétlenül 100%-os. A KSV listája az.
Itt egy hasonló lekérdezés a magyar településekre, GPS koordinátákkal: http://overpass-turbo.eu/s/6tr
Az adatok kinyerése:
EXPORT -> "raw data directly from Overpass API"Az eredmény egy tab szeparált csv lesz, adatai: id, hosszúság, szélesség,név, KSHkód, besorolás, irányítószám, kistérség
Sajnos ebben a településrészek is benne vannak, így az adattisztítást nem úszod meg. Itt megnézheted az OSM cimkéket, amik a településekre vonatkoznak, így a lekérdezést módosíthatod is: [link]
-
rum-cajsz
őstag
válasz
DNReNTi
#2690
üzenetére
Igazából ez nem elméleti kérdés, hanem tervezési. Attól függ, hogy mire fogod használni később a táblát. Ha felosztod külön táblákra, akkor a lekérdezések gyorsabbak lehetnek, illetve az adatírások nem lassítják az olvasást.
Mellesleg ha egy nézetet készítesz a sok tábládra, akkor nem kell mindig a joinokkal vacakolni, elég a nézet nevét használnod. Ha primary keyen kapcsolódnak, akkor az index mentén a join nem számottevő.Nehéz erre tanácsot adni mert ismerni kellene a rendszereteket, és a felhasználási módokat, de ha nagyobb adatmennyiségről van szó (több százezer) akkor én a több táblás megoldást választanám. Ha csak pár ezer felhasználóról van szó, akkor édesmindegy, válaszd azt, ami közelebb áll a lelkedhez.
-
#2515
rum-cajsz
őstag
dellfanboy
#2514
rum-cajsz
őstag
válasz
dellfanboy
#2514
üzenetére
Ha a plsql a PL/SQL Developer nevű programot jelenti, akkor elég hamar találhattál volna választ a súgójában.
Ezt a témát keresd: "Updating the database"De ha sokat csinálsz ilyet, és nem csak egyszeri alkalomról van szó, akkor valószínűleg egyszerűbb lenne a text importer (Tools menü)funkcióját használni a programnak, ami CSV formában eszi meg az excel adataidat.
-
#2476
rum-cajsz
őstag
PumpkinSeed
#2475
rum-cajsz
őstag
válasz
PumpkinSeed
#2475
üzenetére
Na jó, de mi a kérdés?
Szerintem a $switch_lok változód nem kap értéket. Vagy esetleg érvénytelen értéket kap, hibás deklarálás miatt. -
#1589
rum-cajsz
őstag
Apollo17hu
#1588
rum-cajsz
őstag
válasz
Apollo17hu
#1588
üzenetére
Ez az SQL szabvány szerinti, de csak az Oracle esetén új, más adatbáziskezelőkben ez volt a megszokott
from egytabla t1
join kettotabla t2 on t1.id = t2.id
join haromtabla t3 on t1.id = t3.idEz a leegyszerűsített, az Oracle optimalizáló állítólag ezt jobban szereti:
from haromtabla t3, kettotabla t2, egytabla t1
where t3.id = t1.id
and t2.id = t1.idMellesleg az új Oracle esetén azt jelenti, hogy kb. 10-12 éve került bele....
-
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. -
-
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?
-
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/ -
#1304
rum-cajsz
őstag
Sk8erPeter
#1303
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)
-
#1294
rum-cajsz
őstag
Sk8erPeter
#1292
rum-cajsz
őstag
válasz
Sk8erPeter
#1292
üzenetére
"Gondolom erre a képre gondoltál: [link]. "
Haha, ez király!
-
#1275
rum-cajsz
őstag
Yushchenko
#1274
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.
-
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.
-
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.... -
#1214
rum-cajsz
őstag
Sk8erPeter
#1213
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.
-
#1153
rum-cajsz
őstag
Speeedfire
#1152
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.
-
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.
-
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.
-
#1044
rum-cajsz
őstag
InfiniteReality
#1042
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 -
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; -
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.
-
-
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. -
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.
-
-
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?
-
#750
rum-cajsz
őstag
WonderCSabo
#747
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...
-
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.
-
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] -
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) -
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
Új hozzászólás Aktív témák
- Megyünk a CES-re! Mi várható?
- Cseresznyepiros és mokka barna Redmi Note 15-ök az újévre
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Luck Dragon: Asszociációs játék. :)
- Gyúrósok ide!
- OLED TV topic
- Sorozatok
- Megtartotta Európában a 7500 mAh-t az Oppo
- NFL és amerikai futball topik - Spoiler veszély!
- Energiaital topic
- További aktív témák...
- Apple iPod Video (5. Gen) 30GB - A1136 - Wolfson DAC - Gyűjtői állapot!
- Olcsón! LG 34WR55QC-B 100Hz 21:9 UltraWide USB-C PD Machez is! Gari: 2027.áprilisig.
- Liquid Freezer III 360 - használt, garancia: Alza 2031.02.16-ig - ALKUKÉPES.
- Asus Rog Strix G513 144hz Laptop Eladó!
- Mobil LTE hotspot router TP-Link M7200 V4 4G/LTE 150Mb/s,WiFi 2,4GHz 300M
- Pokémon Trading Card Game csomag BONTATLAN
- GYÖNYÖRŰ iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS4055
- Apple iPhone 15 Pro Max 256GB,Átlagos,Dobozaval,12 hónap garanciával
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- Telefon felvásárlás!! Samsung Galaxy S21/Samsung Galaxy S21+/Samsung Galaxy S21 Ultra
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest