Ja, hogy névtelen blokkba kéne szervezni az eljárásokat hívó kódot, és akkor a változó végig deklarálva maradna a blokk végéig?

declare
változó1 típus;
változó2 típus2;
begin
set változó = valami;
exec sp1;

set változó = valami2;
exec sp2;
...
end;

Hello IT! Have you tried turning it off and on again?

Ha nincsen tele GO-val, akkor még ez sem kell. Simán felül tudod írni a változót a blokkon belül set/select-el.

Csak később vettem észre, hogy GO van az EXEC-ek után, úgy persze, hogy mindig újra kell deklarálni.

Persze jó lenne tudni, hogy pontosan mi a terv, mert így csak kb. találgatunk, hogy most mivan.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Alapból, vagy amit konfigurálsz az SSMS-ben.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

jó lett volna, ha leírod, hogy milyen adatbáziskezelőről van szó.
a későbbi hsz-eid alapján ha találgatnom kellene, azt írnám, hogy mysql.
miért nem postgresql?

igen, jól érted. a jól normalizált adatszerkezet lényege, hogy később sem kell belenyúlni. ha most rakás táblád van és azt később bővíteni kell, akkor a lekérdezésekbe is bele kell nyúlni, meg mindenbe.

a lényeg, hogy el kell választani a logikai sémát a tárolási sémától. a logikai séma azt mutatja meg, hogy hogyan kell kinézzen az adatbázis, miután normalizáltad. a tárolási séma meg azt, hogy indokolt esetben miben tér el a logikai sémától.

amit emlegettek mások is, ha nagy a tábla, akkor lehet particionálni a táblát. ráadásul ha külön tablespace-be teszed a partíciókat, akkor a diszk elérés is gyorsulni fog (régen a mysql tudott raid0-t, de kivették belőle...)

mondjuk az is relatív, hogy kinek mi a nagy adatbázis. a postgesql párszázmillió rekorddal még szépen elgurul. utána kell elkezdeni tákolni a tárolórendszert hozzá.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ha csak SQL parancsok vannak a scriptben akkor nem kell a / a végére, de ha van benne PL/SQL is akkor kell.
Ezt én is megszívtam párszor, szintén telepítő scriptek írásakor...

Köszi Ispy, ez lesz az.
Set-tel írnám felül a futások között simán csak addigra már nincs mit.
A GO-t csak a végére teszem, kipróbálom.

Antonio Coimbra de la Coronilla y Azevedo, bizony!

Sziasztok!

Olyan problémám van, hogy van egy 3rd party program, ami SQL-en tárol adatokat. Az a gép, ami ezt a programot futtatja sajnos elromlott, de közben (sok fagyás és újraindulás volt) készített olyan bejegyzéseket az SQL adatbázisban, amit 2021.12 hónapra dátumozott.
Most már rendben működik a gép és a rajta futó program. De sajnos a hibás dátumú bejegyzések miatt az SQL adatbázist nem tudja normálisan kezelni. Pl nem tudja archiválni és régi archívumokat sem tud felcsatolni.
Arra gondoltam,.hogy azokat a bejegyzéseket ki kellene törölni az adatbázisból, amik hibás dátummal lettek rögzítve, de ilyesmire ez a program nem ad lehetőséget. Milyen módszerrel lehetne ezt megtenni?
Sajnoa én egyáltalán nem értek az SQL-hez szóval, ha lehet, akkor részletesen írjátok le.

Előre is nagyon köszönöm mindenki segítségét!

Olyan nincs, hogy valami nem sörnyitó ....

Hát ez így elég mission impossible, nem ismered a programot, a működését, se a db felépítését, elég orosz rulettnek hangzik belepikszkálni, akár totál crash is lehet a vége.

Ja és még az SQL-hez sem értesz, hmmm, nem tudom mit lehetne tenni. Az biztos, hogy bármit is csinálsz, előtte legyen egy backupod, ha gáz van.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Jelenleg egy lokál gépen futó DesktopServer nevű környeztet használok a fejlesztésre. Itt MariaDB van használatban.

Ha van valakinek egy szabad 5 perce, csak akkor olvasson tovább.

Ez egy "itthoni tanulós projekt", semmi több. Érdekelt a téma, így elkezdtem egy weblapot készíteni 6 hónappal ezelőtt. De ekkor kezdtem el csak az alap dolgokon felül használni mindent, ami kell hozzá: HTML, CSS, JS, PHP, SQL.

Nagyon szépen haladtam mindennel, 6 hónapja minden szabadidőmet beleöltem, és most már úgy láttam, 2 héten belül készen vagyok, és költözhetek a kis projektemmel a szolgáltatóhoz: Versanus, velük van pozitív tapasztalatom korábbról. Nem tudom, hogy ott milyen adatbáziskezelő van.

Na szóval örültem, hogy végre a kis projektemet a "nagyvilág elé tárhatom" (értsd: rokonok és kollégák ), és a todo-listám egyik utolsó eleme volt, hogy utánakérdezzek, hogy a lekérdezéseim nem pazarólak-e.

És mint kiderült, sajnos rossz logika mentén építettem fel az egész adatbázist. És az a baj, hogy 6 hónapja amióta csinálom, erre a logikára épül minden de minden. Tegnap átnéztem a kódjaimat, nyilván az új típusú (1 db) táblát könnyen létrehoztam, a tartalomfeltöltő php kódot is könnyen átírtam az ajánlás alapján, hogy a több tábla helyett egybe írjon csak, külön oszlopba pedig, hogy melyik forrásból származó bejegyzéseket tárolja.

De aztán jöttek a JS-ek, plusz a lekérdezésért felelős PHP, és ott sajnos csak nagy nehézségek és időveszteséggel tudnám csak átírni az egy táblás módszerre, hogy szépen működjön. Sajnos nem erre a logikára építettem fel, így kvázi kezdhetném előröl, mert másképp csak a régi módszer kódjait tudom "megerőszakolni", és mivel arra építettem fel mindet, sosem lesz szép tiszta igazán, csak ha előröl kezdem.

És őszintén, ez most nagyon elvette a kedvem. Tökre örültem, hogy végre 6 hónap fáradozása a számomra tök ismeretlen területen végre manifesztálódik, erre kiderült, hogy nagyjából kezdhetem előröl.

Mielőtt tényleg így döntenék, kérlek, írjátok meg, tényleg akkora gond-e, ha külön táblákban vannak az adatok.

Források szerint készítettem el őket, 1 forrás - 1 tábla. Nagyon max 15-20 forrásból fogok dolgozni. Forrásonként naponta kb. 100 bejegyzéssel.
1 bejegyzéshez tartozik egy id, egy link, egy rövidebb és egy hosszabb szöveg (300 karakter max), illetve 2 kép linkje (csak link), plusz még 2 rövidebb tartalmú szöveg (50 karakter max). Ennyi.

Most már én is látom, hogy sokkal jobb lett volna az 1 tábla, mert minden bejegyzés pontosan ugyan olyan felépítési, ugyanolyan oszlopok vannak minden táblában.

Viszont a kódjaim most tökéletesen működnek, millió ellenőrzést és vizsgálatot tettem beléjük, próbáltam minden eshetőségre felkészíteni. És sajnos a sok táblás megvalósítás egyáltalán nem kompatibilis az 1 táblással, tényleg át kellene írnom mindent, JS-től kezdve PHP-kig mindent, még HTML-eket is.

És ha nem szörnyen rossz, tarthatatlan, pocsék lassú a mostani felépítés (max 15-20 tábla, napi 100 bejegyzés / tábla, tehát 2000 bejegyzés / nap, 14e bejegyzés / hét, 728e bejegyzés / év), akkor nem kezdeném előröl.
Az nagyon visszavetne, már így is elszállt a kedvem.

Bocs, hogy hosszan taglaltam ezt, de kérlek, írjátok meg, valóban elengedhetetlenül szükséges-e előröl kezdenem az új szerkezettel. A rokoni/kollegális elérésekhez biztosan nem.
De később, ha a fél ország ezt olvassa majd (best case scenario ), lehet valami hátulütője a több táblás felállásnak? Ha egyszerre 5 millióan nézik az oldalt, lapoznak, futnak a lekérdezések (LIMIT 4, szóval 1 lekérdezés csak max 4 találatot ad vissza mindig), milyen negatív következményei lehetnek, ha a több táblásnál maradok? Lelassul minden mindenkinek? Vagy a szolgáltató szól rám?

Ezt összefoglalnátok nekem pár gondolatban, kérlek?

Eléggé elkeseredtem most, de persze ha ez a több táblás módszer a fenti számolásokat alapul véve is tarthatatlan, és később csak problémám lenne belőle (belassulna az oldal a felhasználóknak), akkor egyelőre hagyom az egészet, és majd ha megint találok rá ennyi időt egyszer, átírom.
De ha csak a tábla karbantartása miatt lenne jobb, ha egy lenne a több helyett, akkor az nem gond, mert mindent eleve a több táblásra készítettem el.

Köszönöm, és elnézést az eszméletlen hosszú posztért, de 2 sorban ezt nem lehet (vagy csak én nem tudtam) rendesen elmagyarázni.

Hát ugye, mentés létezik róla, de a komplett virtuális gép van időnként lementve, amin fut az SQL. Ráadásul a hibás dátumú bejegyzések után születtek már "jó" bejegyzések is, amik nem lenne baj, ha meglennének.

Olyan nincs, hogy valami nem sörnyitó ....

A backup-ot megoldom, de mi legyen az a "bármi" ?

Olyan nincs, hogy valami nem sörnyitó ....

Hát én első körben csinálnék egy backupot, majd abból egy restore-t és elkezdenék "nézelődni" a tablákban, ha egyáltalán hozzáférsz és nincs letíltva. Aztán ha sikerül felderíteni a rossz adatokat, akkor lehet törölni, majd tesztelni és ha megy a copy db-n, akkor megcsinálni ugyanezt az élesen is.

De ez egy realációs adatbázis, szóval lehet, hogy több táblából is kell törölni, lehet megfelelő sorrendben, mittudomén, innentől már egy db expert is megízzadna ezzel a feladattal.

Mivel nem látjuk/tudjuk mennyi tábla van, mekkora a db (lehet-e egyáltalán restore-t csinálni?), kb. semmit nem tudunk, így ez elég távgyógyítás gyanús eset.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Köszi mindenkinek!

Olyan nincs, hogy valami nem sörnyitó ....

Ezt fogd fel tanulópénznek, és igen, mindenképp írd át normálisra a táblastruktúrát. Legalább ezzel is tanulsz.
Illetve máskor lehet nem árt kérdezni, mielőtt magadtól kitalálsz valami butaságot, és 6 hónapig rossz irányba mész (jó persze sokszor a kérdezéshez is már kell egy alap tudás...).

Egyúttal szólok előre, hogy az ilyen vicc tárhelyeknél, majd még csak ezután fog kezdődni a kálváriád, amikor ki fog derülni, hogy MariaDB-t nem támogatnak
A helyedben egyből a felhőt céloznám meg (ok, ott meg nem évi 10K HUF lesz a hosting, bááár lehet, lusta vagyok utána nézni a DB áraknak).

Én kérek elnézést!

Azt nem tudod belegyógyítani a közös táblát író insertbe, hogy HTML requestben megkapott domain függően töltse ki a forras mezőt?
Illetve a weblapnak választ adó selectekbe is?

insert into ujtabla (forras, mezo1, mezo2...)
select
case when domain = 'elsoweblapom.hu' then 'forras1'
when domain = 'masodikweblapom.hu' then 'forras2'
end forras,
mezo1,
mezo2,
...

De akkor már elegánsabb lenne felvenni egy szótár táblát, amiben megadod a domain - forrás összerendeléseket, és ez alapján joinolod a selecteket.
Így már nem kell majd hozzányúlni a kódhoz amikor új forrást veszel fel, hanem csak egy új sort kell felvenni a forrasok táblába, és működni fog az új weblap is.

create table forrasok (
domain varchar(100),
forras varchar(10)
);

insert into forrasok (domain, forras)
values ('elsoweblapom.hu','forras1');

insert into forrasok (domain, forras)
values ('masodikweblapom.hu','forras2');

insert into ujtabla (forras, mezo1, mezo2)
select f.forras, v.mezo1, v.mezo2
from html_valasz v
join forrasok f
on f.domain=v.domain
...

select t.*
from ujtabla t
join forrasok f
on f.domain = html_domain
where t.forras = f.forras
and ...

Remélem érthető a gondolatmenetem.

Egyébként meg az ilyen mellényúlásokból tanul a legtöbbet az ember.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Nem vagyok otthon a webfejlesztésben, de ehhez érzésem szerint csak a DBt hívó PHP rétegbe kell belenyúlni, HTML, JS kód nem nagyon módosul.

Hello IT! Have you tried turning it off and on again?

Igen, igazatok van, nem rinyálok, nekiülök és megcsinálom. Köszönöm, hogy elolvastátok azt a hosszú bejegyzést, és köszönöm az iránymutatást.

@nyunyu: Köszönöm szépen, hogy ilyen részletesen leírtad ezt a processzt. De nem akarom megtartani a táblák jelenlegi tartalmát, naponta töröltem eddig a tesztek miatt.

majd még csak ezután fog kezdődni a kálváriád, amikor ki fog derülni, hogy MariaDB-t nem támogatnak

Így gondolom, ez sem fontos, mert a (remélhetőleg) végleges adatbázist tartalommal majd ott kezdem el felépíteni és feltölteni.

Úgy látom, a PHP-oldali résszel készen vagyok (nagy meglepetésemre).

Viszont a kereséshez (és szűréshez) kapcsolódó lekérdezések még mindig a "régi csúnyák":

Így néz ki jelenleg, ha keresést indítok 3 különböző szóra:
SELECT * FROM the_only_one_table
WHERE 
((title LIKE '%kereso_szo_1%'
AND
title LIKE '%kereso_szo_2%'
AND
title LIKE '%kereso_szo_3%')
OR
(description LIKE '%kereso_szo_1%'
AND
description LIKE '%kereso_szo_2%'
AND
description LIKE '%kereso_szo_3%')) 
AND 
id NOT IN (672,467,439,395,325,143,10,156) 
ORDER BY date DESC 
LIMIT 4

(az id NOT IN részt csak azért hagytam benne, hogy megmutassam, hogy megfogadtam a tanácsaitokat, és így valóban kulturáltabb az egész )

A kereséshez (és ugyanilyen elven (LIKE %%-kal) működik a szűrés is):
Az ajánlás alapján rákerestem a full text search-re. Ott elsőnek a CONTAINS-t találtam. De kézzel (phpMyAdmin-ban a konzolban) sem adott vissza találatot:

WHERE CONTAINS ((title, description),'"kereso_szo_1" AND "kereso_szo_2" AND "kereso_szo_3"')

Láttam keresési találatokat MATCH-re, MATCH AGAINST-re, de a leírásuk sem győzött meg, hogy ezeket kellene használnom.

Szóval martonx tanácsát megfogadva inkább rákérdezek, hogy hogyan lehetne megoldani a keresést/szűrést a a LIKE %% használata nélkül?
Engem -tapasztalatlant- persze nem zavar, csak ugye írtátok, hogy rém pazarló. A LIKE-nál keresés miatt pedig muszáj vagyok a %%-ot használni, mert a szöveg bármelyik pontján lehetnek a keresett szavak.

Köszi!

Full Text search-öt előbb a DB-ben be kell kapcsolni fel kell paraméterezni (az általad linkelt fisfos hosting cégeknél pláne erősen kérdéses, hogy be tudsz-e ilyet kapcsolni). Bevallom én még sose használtam, mert nem kellett. Igaziból, ha nem sok millió, egészen nagy méretű szövegben kell keresned, akkor szerintem a Like is simán megteszi.
Full text search helyett én pl. hehe a Google-t használom a weboldalaimon, amiket a Google egyébként is indexel
Programmable Search Engine | Google Developers
Így nem az én DB-mnek kell belegebednie az oldalon keresések kiszolgálásába, hanem a Gugliénak, ráadásul ingyen.

Én kérek elnézést!

Ügyes trükk.
De akkor ezek szerint nekem pár évig maradhat a LIKE is még.
300 és 500 karakterre van korlátozva a 2 mező, amikben a keresés folyik, és nagyon max 800e bejegyzés születik majd évente, amiken a keresésnek végig kell mennie.

300 és 500 karakter között
Akkor bőven jó lesz a Like is még nagyon sokáig (már ha a fisfos hosting vicc mysql szervere is úgy akarja).
De a fulltextsearch-öt ráérsz majd akkor bekapcsolni (vélhetően hosting váltással együtt), amikor elkezd köhögni az oldal.

Én kérek elnézést!

Az ingyenes DBeaver-t használom sqldb mentésekhez.
A MySQL-t nem ismerem, nem tudom hogy a dumphoz elég csak a schéma fájlokat menteni vagy a technikai sémákat (information, performance) is vinni kell a mentésnek?

nem szükségesek a mentéshez ezek a sémák

Hi,
Van egy feladat amivel szívok egy ideje. Van 2 tábla amiben dátumok vannak egy ID-val ezeket kellene kombinálnom őket 1 viewba ahol egymás mellett hozom a dátumváltozásokat. Pl.
T1(ID, Date1, Attr1):
1, 2018.01.01, A
1, 2018.02.01, B
1, 2018.03.01, C
1, 2018.03.20, D

T2(ID, Date2 Attr2):
1, 2018.01.09, F
1, 2018.03.01, G
1, 2018.03.03, H
1, 2018.03.22, I
1, 2018.03.25, J

A VIEW elvárt eredménye:
ID, Date1, Date2, Attr1, Attr2
1, 2018.01.01, null, A, Null
1, 2018.01.01, 2018.01.09, A, F
1, 2018.02.01, 2018.01.09, B, F
1, 2018.03.01, 2018.03.01, C, G
1, 2018.03.01, 2018.03.03, C, H
1, 2018.03.20, 2018.03.03, D, H
1, 2018.03.20, 2018.03.22, D, I
1, 2018.03.20, 2018.03.25, D, J
(Ez talán tartalmaz minden esetet amivel szívok), Amúgy MS SQL.
Eddig bármit raktam össze valamelyik sor hiányzott, vagy nem a megfelelő volt a Date1. Mindkét táblában vannak még további attributumok és azokat is hozni kell a dátum oszlop alapján. Egy táblában dátum ismétlődés nincs, de van még egy Valid_from Valid_to oszlop is ahol a Valid From az a Date1/2 a Valid_to a következő rekord Date1/2-je, ha ez segít...

Bármi ötletet szívesen veszek.

Csináltam hozzá egy SQL Fiddle -t is. Hátha úgy könnyebb.

Javított fiddle
Az utolsó T2-es adat rossz volt.

In case anyone is interested in:
Született egy megoldás, most integrálom a való világba.:

with
dt AS
(
select valid_from d from t1
union
select valid_from d from t2
)
select
    dt.d
  , coalesce(t1.id, t2.id) as id
  , t1.valid_from  as date1
  , t2.valid_from  as date2
  , t1.attr1
  , t2.attr2
 from dt
      left outer join t1 on (dt.d >= t1.valid_from and dt.d < t1.valid_to)
      left outer join t2 on (dt.d >= t2.valid_from and dt.d < t2.valid_to)

és egy másik:
select
    t1.id
  , t1.valid_from  as date1
  , t2.valid_from  as date2
  , t1.attr1
  , t2.attr2
 from t1 left outer join t2 on (
   (t1.valid_from  >= t2.valid_from and t1.valid_from < t2.valid_to)
 )
union
select
    t2.id
  , t1.valid_from  as date1
  , t2.valid_from  as date2
  , t1.attr1
  , t2.attr2
 from t2 left outer join t1 on (
   (t2.valid_from  >= t1.valid_from and t2.valid_from < t1.valid_to)
 )

Beregeltem én is, hátha máskor itt is tudok segíteni...

Welcome itt is! És köszi a tippeket.

Nem ezt akarod inkább lekérdezni?
with t1t2 as
(select t1.ID, t1.Date1 as Date, t1.Attr1, null as Attr2, t1.valid_from, t1.valid_to
from t1
union
select t2.ID, t2.Date2 as Date, null as Attr1, t2.Attr2 as Attr2, t2.valid_from, t2.valid_to
from t2)
select distinct
akt.id,
akt.date valid_from,
lead(akt.date) over (order by akt.date) valid_to,
ut1.attr1,
ut2.attr2
from t1t2 akt
left join t1t2 ut1
on ut1.id=akt.id
and ut1.valid_from<=akt.date
and ut1.valid_to>akt.date
and ut1.attr2 is null
left join t1t2 ut2
on ut2.id=akt.id
and ut2.valid_from<=akt.date
and ut2.valid_to>akt.date
and ut2.attr1 is null
order by akt.id, akt.date;

Összefűztem a két táblát, majd minden dátumhoz megkeresem az adott pillanatban érvényes Attr1 és Attr2 értékeket, meg a következő változás dátumát.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Ez hasonlít az első megoldáshoz de ott egy distinct-tel és 1 lead-del kevesebb számolás kellett. Azt végülis sikerült teljesen beintegrálnom a valós rendszerbe és hozza is a lent leírt eredményt.

Azért köszönöm a tippet.

Mai színes:

Oracle alól indítva
select *
from tabla@SQLSERVER
where id=1;

Visszajön egy ilyen hibaüzenet:
[Microsoft SQL Server]Error converting data type varchar to numeric {HY000, NativeErr = 8114}

where id='1';

Dettó ugyanaz a hiba.

where to_number(id)=1;
Működik...

where masikid=2;
Bezzeg ez is működik...

Megfejtés:
id numeric(10,0)-nak, masikid numeric(3,0)-nak van castolva a MSSQL oldali viewban.

Fene se érti, miért hasal ez el a két DB közti adatkonverziós rétegen.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Üdv!

PostgreSQL-ben timestamp alapján szeretnék GROUP BY-olni a következő módon: adott egy timestamp mező másodperces felbontásban és a cél az lenne, hogy azok a sorok kerüljenek összevonásra, amelyek közül a min és a max közti időkülönbség nem nagyobb 1 percnél.
Tehát pl. a '2021-06-08 10:11:34' és a '2021-06-08 10:12:10' össze kell, hogy vonódjon. Addig megoldottam, hogy perces bontásban legyenek csoportosítva, de ez így nem az igazi, mivel 2 másodperc különbség miatt (változik a perc, egyiknél 0 perc 59 másoderc, másiknál 1 perc 01 másodperc) is külön csoportba kerülnek.

Jelenleg így néz ki:

SELECT 
  COUNT(*), 
   date_trunc('hour', datetime) +   (
    (
      (
      date_part('minute', datetime):: integer / 1 :: integer
      ) * 1 :: integer
    )   || ' minutes'
  ):: interval AS one_min_timestamp 
FROM 
  table 
GROUP BY 
  one_min_timestamp 
ORDER BY 
  one_min_timestamp;

Van esetleg valami tippetek miként lehetne ezt továbbfejleszteni a fentebb felvázolt módon?

Nem lenne egyszerűbb az időbélyegek különbsége alapján számolni?

SQL szabvány szerint mint a dátum, mind az időbélyeg típusok kivonhatóak egymásból és akkor kapsz egy időintervallumot.
Vagy dátum+időintervallum=dátum, időbélyeg+időintervallum=időbélyeg!

Én legalábbis úgy nézném meg, hogy mi a legsűrűbben logolt környék, hogy önmagával összejoinolnám a táblát, hogy a második rekord időbélyege nagyobb legyen, mint az elsőé, és a különbségük egy percen belül legyen, aztán ezt a halmazt group by-olnám az első időbélyegre, és megszámolni, hány második tartozik hozzá.

valami ilyesmire gondoltam:
SELECT y.date, y.cnt
FROM (
SELECT x.date, count(x.date2) cnt
FROM (
SELECT a.date, b.date as date2
FROM table a
JOIN table b
ON b.date > a.date
AND b.date < a.date + interval '1' minute) x
GROUP BY x.date) y
ORDER BY y.cnt desc;

Itt az erős join miatt csak azokat az dátumokat/időbélyegeket fogod visszakapni, ahol egy percen belül volt legalább egy másik bejegyzés.
Magányos, kósza bejegyzéseket nem! (mondjuk a b.date >= a.date feltétellel azokat is figyelembe lehetne venni.)

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Köszi a választ, megnéztem ezzel a kóddal, de sajnos így az egymást követő sorokban a dátumok között csak 1-2 másodperc a különbség, és hiába állítom az interval értékét 1 percről akár 1000-re, ugyanazokat a dátumokat adja vissza. Kb. ugyanazt az eredményt adja, mint amikor egy egyszerű DISTINCT date-et futtatok a táblára. Legalább is a visszaadott sorok száma azonos.

Nem teljesen értem, hogy mit is szeretnél igazából.
Leválogatni a legsűrűbb időbélyeg környékeket?
Listázni az időbélyegeket, és a tőlük max 1 percre lévő logbejegyzéseket?

Utóbbira valami ilyesmit tudnék elképzelni:
SELECT *
FROM (
SELECT a.date min_date,
row_number() over (group by a.date order by b.date) rn,
b.*
FROM table a
JOIN table b
ON b.date >= a.date
AND b.date <= a.date + interval '1' minute)
ORDER BY min_date, rn;

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Esetleg összefűzni az egy percen belüli logbejegyzéseket?
SELECT min_date,
listagg(b.log, chr(10)||chr(13)) within group (order by rn) log_list
FROM (
SELECT a.date min_date,
row_number() over (group by a.date order by b.date) rn,
b.*
FROM table a
JOIN table b
ON b.date >= a.date
AND b.date <= a.date + interval '1' minute)
GROUP BY min_date
ORDER BY min_date;

(Nem tudom, hogy néz ki a listagg postgresql megfelelője.)

Hello IT! Have you tried turning it off and on again?

Esetleg összefűzni az egy percen belüli logbejegyzéseket?
SELECT x.min_date,
listagg(x.log, chr(10)||chr(13)) within group (order by x.rn) log_list
FROM (
SELECT a.date min_date,
row_number() over (group by a.date order by b.date) rn,
b.log
FROM table a
JOIN table b
ON b.date >= a.date
AND b.date <= a.date + interval '1' minute) x
GROUP BY x.min_date
ORDER BY x.min_date;

(Nem tudom, hogy néz ki a listagg postgresql megfelelője.)

Hello IT! Have you tried turning it off and on again?