Új hozzászólás Aktív témák
-
nyunyu
félisten
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?
-
Ispy
veterán
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."
-
nyunyu
félisten
válasz xabolcs #4952 üzenetére
Még mindig nem jöttem rá, mi a logikája a /-ek elhelyezésének a telepítő szkriptekbe, hogy sqlplus kompatibilis legyen, így inkább minden DDL-t záró ; utáni sorba kirakom.
(Azt meg végképp nem értem, miért nem tudnak az üzemeltetők értelmes DB buherátort használni élesítéskor.)
Hello IT! Have you tried turning it off and on again?
-
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
-
nyunyu
félisten
válasz bambano #4956 üzenetére
mondjuk az is relatív, hogy kinek mi a nagy adatbázis. a postgesql párszázmillió rekorddal még szépen elgurul
8 éve próbálkoztam az egyik mobilszolgáltató adattárházán dolgozni, aztán a DB műveletek query planjét logoló táblából (~napi 10 millió rekord?) kellett volna adatokat kinyernem egy adatvizualizációs projekthez.
Próbaképpen lekértem negyedórányi adatot, erre 10 perccel később jött a teradata üzemeltető leordítani a hajamat, hogy ilyet ne merjek még egyszer lekérdezni, mert letérdelt tőle a 24 node-os DWH, alig bírták kilőni a querymet.
Pedig előtte direkt megnéztem, milyen indexek vannak a táblán, meg mekkora a várható eredményhalmaz mérete, nehogy egyszerre túl sokat akarjak lekérdezni...
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
martonx
veterán
Előző munkahelyemen a legnagyobb táblában 6 milliárd sor volt, és naponta pár tíz millióval bővült. Ebben csak az volt a pláne, hogy tök sima MSSQL vitte a DB-t egy 32 magos 256Gigabyte memóriás szerveren AWS-ben.
Mondjuk nyilván még ez se volt semmi a telkok DB-ihez képest.Én kérek elnézést!
-
ratkaics
senior tag
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ó ....
-
Ispy
veterán
válasz ratkaics #4961 üzenetére
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."
-
Taci
addikt
válasz bambano #4956 üzenetére
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.
-
Ispy
veterán
Hogy röviden válaszoljak: ha szar, át kell írni. Pont.
Nem te vagy a történelembe az első, aki lyukra futott, ne aggódj, ráadásul kezdő vagy. Ez a hiba most egy tapasztalat, az ember így tud fejlődni, senki sem úgy kezdi, hogy miden kódja tökéletes már a legelső kódsortól kezdve. Ne sajnáld az időd a hibáid feltárására és kijavítására, mert persze, ez most így könnyebbnek tűnik, de így csak a szönyegalá sepred a dolgot és később is lesz mindig fájdalommentesebb út.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
ratkaics
senior tag
-
Ispy
veterán
válasz ratkaics #4968 üzenetére
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."
-
martonx
veterán
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!
-
nyunyu
félisten
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?
-
nyunyu
félisten
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.
Ne emlegesd, pont egy ilyen banki projekten dolgozom 1 hónapja...
Mindenféle custom Java alkalmazás alatti ~250 Oracle táblából kell kigyalulni a rég lejárt adatokat, de persze egyikhez sincs semmi doksi, fejlesztők már rég máshol dolgoznak, meg a táblák nagy részén nincsenek foreign keyek, nehogy véletlenül lássuk, melyik tábla melyikhez kapcsolódik adattartalomra.
ER diagram? Ha rajzolok, akkor talán lesz.Törlést végző cuccot elődeim szerencsére már megcsinálták, már csak az alkalmazások forráskódjából kell kihámoznunk, hogy mi hova joinolódik, hogy sorba rendezhessük a 250 táblát, hogy miből mit kell előbb törölni, és csak utána lehet a rájuk hivatkozó rekordokat.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Taci
addikt
válasz martonx #4971 üzenetére
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. -
Ispy
veterán
Hát igen, normál esetben vagy van egy cascade del, vagy egy trigger, ami kitörli az összes kapcsolódó rekordot, neadjisten még ellenőrzi is, hogy lehet-e törölni. De most képzeld el mit csinálnál a sok szabadidődben, ha nem kéne nyomozósdit játszanod?
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Taci
addikt
Ú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!
-
martonx
veterán
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!
-
martonx
veterán
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!
-
Taci
addikt
válasz martonx #4980 üzenetére
Amúgy azért őket választottam, mert habár saját HTML (és CSS, JS, PHP, SQL) kódot írtam, nem tudom, hogyan "védhetném" meg az oldalamat a különböző féle (általános) támadások ellen. Ezért eleve abból indultam ki, hogy WordPress-re van millió kiegészítő, van pár (elvileg) nagyon jó, ami a biztonságért felel (pl. Wordfence), így némi kompromisszummal, de tudom a 2 világot (saját kódok szabadsága + WordPress biztonsága) kombinálni.
Régebben amikor WP-t tanultam, akkor ajánlották és használtam a Wordfence plugint, azokból a reportokból láttam, hogy mennyi mindent megfogott. Fogalmam sincs, hogyan kell/lehet egy weblapot/tárhelyet másképp megvédeni, és védeni pedig sajnos van mitől, nem a backup-ok visszaállításával szeretném az időmet majd tölteni.
Na de ez teljesen más téma (security), amihez még annyira sem értek, mint az SQL-hez (és az sem sok... ), szóval muszáj vagyok már kész megoldásokat és rendszereket használni, mert erre tényleg nincs már időm/energiám 0-ról megtanulni (mert elég nagy témakör, ha jól sejtem.) -
Ablakos
őstag
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? -
tm5
tag
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, DT2(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, JA 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.
-
tm5
tag
Csináltam hozzá egy SQL Fiddle -t is. Hátha úgy könnyebb.
-
tm5
tag
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) -
tm5
tag
é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)
) -
kojakhu
újonc
Beregeltem én is, hátha máskor itt is tudok segíteni...
-
nyunyu
félisten
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?
-
nyunyu
félisten
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?
-
kw3v865
senior tag
Ü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? -
nyunyu
félisten
válasz kw3v865 #4995 üzenetére
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?
-
kw3v865
senior tag
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.
-
nyunyu
félisten
válasz kw3v865 #4997 üzenetére
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?
-
nyunyu
félisten
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?
-
nyunyu
félisten
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?