Új hozzászólás Aktív témák
-
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.)
-
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.)
-
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; -
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
#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.) -
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:
SELECTCOUNT(*),date_trunc('hour', datetime) + (((date_part('minute', datetime):: integer / 1 :: integer) * 1 :: integer) || ' minutes'):: interval AS one_min_timestampFROMtableGROUP BYone_min_timestampORDER BYone_min_timestamp;
Van esetleg valami tippetek miként lehetne ezt továbbfejleszteni a fentebb felvázolt módon? -
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.
-
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.
-
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)
) -
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
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.
-
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.) -
martonx
veterán
-
-
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. -
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_tableWHERE((title LIKE '%kereso_szo_1%'ANDtitle LIKE '%kereso_szo_2%'ANDtitle LIKE '%kereso_szo_3%')OR(description LIKE '%kereso_szo_1%'ANDdescription LIKE '%kereso_szo_2%'ANDdescription LIKE '%kereso_szo_3%'))ANDid NOT IN (672,467,439,395,325,143,10,156)ORDER BY date DESCLIMIT 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!
-
-
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. -
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.
-
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.
-
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). -
Ispy
nagyúr
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.
-
Ispy
nagyúr
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.
-
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
nagyúr
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.
-
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!
-
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. -
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...
-
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á.
-
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.)
-
Ispy
nagyúr
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.
-
-
Ispy
nagyúr
válasz
Petya25
#4948
üzenetére
Nem lenne jobb egy etető eljárás? Azt meghívod a paraméterekkel, megcsinálja az insertet és fut a következő.
Egyébként meg simán declare az elején, utána meg set @a=1 vagy set helyett lehet select is, ha nem változik az értéke, akkor meg nem írod felül.
Már ha jól értem mit akarsz.
Egyébként meg a GO miatt dobja a deklarációt, mert az a kódblokk vége, onnantól új kód fut.
Szóval valami ilyesmi kellene:
Declare rész
.
.
Set variables
Exec sp1
.
.
.
Set variables
Exec sp2
.
.
.
Set variables
Exec sp3
.
.
.
GO -
Petya25
őstag
MS SQL-ben kéne valami trükk erre:
Az a problémám, hogy az egyben futtatott több tárolt eljárás előtt újra és újra kell inicializálni a változókat, nem tudom a kód futásban lejjebb a már fenti változót használni.
A tárolt eljárást többször futtatnám és az eredményét minden körben betolom egy átmeneti táblába.1. futás
-- a tárolt eljárás az eredményt eleve egy átmeneti táblába teszi: ##tfo_tomb2
declare @th char(1) = 'F', @dtol datetime = '2021.01.01', @dig datetime = '2021.04.30'
EXECUTE [tfo] @th ,@dtol ,@dig
GO
-- az eredményt elmentem és dobom a temp táblát
select 'F' as th, datum, telepo, ossz
into #tetel_ora
from ##tfo_tomb2drop table ##tfo_tomb2
2. futás
-- na itt már nem tudom használni a fenti változókat újra kell inicializálni őket
declare @th char(1) = 'G', @dtol datetime = '2021.01.01', @dig datetime = '2021.04.30'
EXECUTE [tfo] @th ,@dtol ,@dig
GOinsert into #tetel_ora
select 'G' as th, datum, telepo, ossz from ##tfo_tomb2drop table ##tfo_tomb2
--és ezt még párszor megteszem a @th változó cserélgetésével, de az a rész a kódban
--fix "set" lehetne, viszont a dátumot csak 1x állítanám az elején, de nem eszi meg.... -
nyunyu
félisten
Gondolom utólag akarsz arra is szűrni, hogy honnan származik az adat.
Most ha quick&dirty megoldást akarsz a meglévő táblákban lévő rekordok egy helyre lapátolására, akkor:
create table ujtabla as
select 'forras1' as forras, t1.*
from tabla1 t1;
insert into ujtabla
select 'forras2' as forras, t2.*
from tabla2 t2;
...
insert into ujtabla
select 'forras5' as forras, t5.*
from tabla5 t5;+ az eddigi kódban minden insertbe beleteszed, hogy az új rekordoknál mivel töltse a forras mezőt.
+ az eddigi táblaneveket mindenhol lecseréled ujtabla-ra
+ létrehozod az eddigi táblákra vonatkozó indexeket ujtabla-ra.Ekkor ha mondjuk külön akarnál selectálni a kettes rendszerből, akkor ezután így fog kinézni:
select *
from ujtabla
where forras='forras2'
and ...
order by date desc;lletve PHP oldalról megnézni, hogy az új struktúrájú lekérdezésben hogyan tudnám hatékonyan használni a bind_param-ot. (Ha kell/lehet-e egyáltalán.)
Nem vágom a PHPt, de gondolom a mezők bindelésénél ki kell cserélni a táblanevet az újra, valamint az új forras mezőnek fixen megadni egy értéket. (Mittudomén kettes webshopnál azt, hogy 'forras2', vagy aminek elnevezted)
-
Taci
addikt
Amire kell csak figyelni: összes a táblába szúró insertnél legyen kitöltve a forrásrendszer azonosító.
Ez alatt ezt érted? (Egy korábbi válasz ugrott be a PHP-s topikból ( [link] ), abban láttam ezt először.)
ENGINE=InnoDBEz miért fontos amúgy? Itt amúgy CREATE-nél van. Hol kell/ajánlott ezt használni?
-
Taci
addikt
Köszönöm szépen a sok tanácsot, lesz mit átnéznem/átírnom.
De legalább remélhetőleg stabil kódom/adatbázisom lesz. Még erre a full-text search-ös dolgot kell majd ránéznem.
Illetve PHP oldalról megnézni, hogy az új struktúrájú lekérdezésben hogyan tudnám hatékonyan használni a
bind_param-ot. (Ha kell/lehet-e egyáltalán.) -
nyunyu
félisten
De amúgy tényleg érdekelne, hogy miben/mennyivel "rosszabb", ha több táblában vannak az adatok. Nyilván a sebesség az egyik válasz, ez biztos. De érdekelne, miben még.
Leginkább a kód karbantarthatóságról szól a felvetésünk. (meg olvasni, átlátni is könnyebb a rövidebb, egyszerűsített kódot)
Most ha bejön egy új alrendszer/forrás, akkor kézzel definiálsz neki egy új táblát, arra indexeket, meg a meglévő kódbázisban az összes union-os selectet ki kell bővíteni +1 ággal, hogy az új forrást is visszaadja.
Plusz szopni fogsz, ha bármelyik táblába fel kell venni egy plusz mezőt, mert akkor kézzel alter table az összesre, hogy az unionok továbbra is működhessenek...Míg egy táblánál csak az új forrás adatbetöltő rutinját kell megírnod, ami egy új azonosítóval szúrja be a meglévő táblába a rekordokat.
Plusz oszlop igény esetén meg elég egy táblát alterelni, nem fog elszállni a kód (ha ki van mindenhonnan irtva a select *
) -
nyunyu
félisten
Úgy szeretném megcsinálni, hogy utána szerkezeti változás miatt ne kelljen már "soha" belenyúlni, ezért veszem a fáradságot és időt és átírom, ezzel nincs baj. Csak érteni is szeretném a miértjét.
Ha most nem léped meg a refaktort, és később kiderül, hogy valamelyik táblába fel kell venned pár plusz oszlopot, akkor az összesbe veheted fel egyesével ugyanazokat, ugyanabban a sorrendben, különben hibával elszáll az összes union-os lekérdezésed!
Mondjuk ebből a szempontból a select *-os slendriánság sem egy életbiztosítás
Sokkal elegánsabb, és hibatűrőbb, ha egyesével felsorolod a lekérdezendő oszlopokat + insertnél a beszúrandó tábla oszlopait.magyarul mindenhol így nézzen ki a kód:
insert into tábla (oszlop1, oszlop2, oszlop3)
select oszlop1, oszlop2, oszlop3
from tábla2;Ez nem fog megborulni, ha bármelyik tábla szerkezete módosul.
-
nyunyu
félisten
Akkor meg pláne most kéne meglépni az egy táblára átállást, mert 20 táblánál már sokkal több időt fog igényelni a refaktorálás.
Amire kell csak figyelni: összes a táblába szúró insertnél legyen kitöltve a forrásrendszer azonosító.
Aztán ha alrendszerenként nagyon sok adat van, és az adatbázis licenszed is megengedi, akkor el lehet gondolkozni a forrásrendszer azonosító menti partícionáláson, amikor partíció kulcsonként külön táblateret használ, és mindegyiknek külön épít indexeket.
Ekkor konkrét azonosítóra szűrve ugyanúgy viselkedik a nagy tábla, mintha önálló táblája lenne az alrendszernek viszonylag kicsi adatmennyiséggel, ha meg nem szűrsz, akkor az alrendszerek tábláinak unióját látod. (ez utóbbi nem annyira hatékony, ha a partíciókulcs nincs a join/where feltételben!) -
Taci
addikt
válasz
sztanozs
#4939
üzenetére
Ha jó keresési találatokat nézek, akkor ez az, ugye? (Soha nem hallottam még róla, és amikro azt kerestem anno, hogy tudok keresni szavakra, a LIKE-ot dobta a legtöbb oldal, ezért kezdtem el ezt használni.)
WHERE CONTAINS ((title, description),'"szoveg1" AND "szoveg2" AND "szoveg3"')Ha ez így helyes, akkor ugye mindkét helyről (title, description) ad vissza találatokat, akár egyikben, akár másikban, akár mindkettőben van találat az összes keresett szóra?
@bambano:
Ez azt jelenti, hogy inkább egy táblám legyen csak?
De amúgy tényleg érdekelne, hogy miben/mennyivel "rosszabb", ha több táblában vannak az adatok. Nyilván a sebesség az egyik válasz, ez biztos. De érdekelne, miben még.Úgy szeretném megcsinálni, hogy utána szerkezeti változás miatt ne kelljen már "soha" belenyúlni, ezért veszem a fáradságot és időt és átírom, ezzel nincs baj. Csak érteni is szeretném a miértjét.
Köszi.
-
Taci
addikt
Ha csak 'valami%'-ra alkalmazod a facebook filtert (vagyis ismert a string eleje), akkor legalább a keresendő oszlopra rakott indexből tud dolgozni.
Kereséshez használom, így sajnos nem ismert a sztring eleje, mert a keresett szó bárhol lehet, sor elején, közepén, végén, így muszáj vagyok (jelen ismereteim szerint) így keresni:
LIKE '%szoveg%' -
Taci
addikt
Ez így valóban jó ötlet. Csak sajnos már mindent a külön táblákra felépítve csináltam meg. De ha azt mondjátok, hogy nagyságrendekkel gyorsabb/hatékonyabb/(nem tudom, mit kellene még itt figyelni) lenne ezzel a szerkezettel, akkor rászánom az időt, és átírom az elejétől kezdve.
Kezdjek neki, vagy azért nincs akkora hátránya az 5 táblából való adatszerzésnek a 1 táblával szemben? Főleg úgy, hogy tényleg csak 4 bejegyzést kérek el egyszerre. (Bár amúgy az 5 tábla a jelenlegi struktúrával fel fog szökni kb. 20 táblára.) -
nyunyu
félisten
válasz
sztanozs
#4932
üzenetére
'NOT IN' elég pazarló (legalább is az én ismereteim szerint), persze lehet, hogy a modern motorok már átalakítják kevésbé lassabbakra.
Tizenéve már azt tanították az egyetemen, hogy mindegy, úgyis átalakítja left joinra az optimalizáló.
Gyors futáshoz LEGYEN index a vizsgált mezőn.A LIKE-ok meg szerintem mindegy milyen scope-ban futnak.
Na, az az igazán pazarló, pláne, ha %-gal kezdődik a lájkolnivaló, mert akkor semmilyen indexet nem tud használni hozzá, hanem mindig full table scan lesz a vége.
Ha csak 'valami%'-ra alkalmazod a facebook filtert (vagyis ismert a string eleje), akkor legalább a keresendő oszlopra rakott indexből tud dolgozni. -
nyunyu
félisten
Az 5 táblában 5 különböző forrásból származó bejegyzések vannak, jellemzően több száz (idővel több ezer), ezért vannak már eleve külön táblákba mentve.
Erre felesleges 5 táblát fenntartani, elég lenne egy tábla is, amibe felveszel egy pár karakteres új oszlopot, amibe az forrás azonosítóját írod, aztán ha forrásra kell szűrni, akkor beírsz plusz egy where feltételt a lekérdezésbe.
Amúgy meg kimaradt a külső select:
SELECT *
FROM
(SELECT * FROM table1
UNION ALL
SELECT * FROM table2
UNION ALL
SELECT * FROM table3
UNION ALL
SELECT * FROM table4
UNION ALL
SELECT * FROM table5)
WHERE ID NOT IN (...)
ORDER BY date DESC
LIMIT 4; -
Taci
addikt
Az 5 táblában 5 különböző forrásból származó bejegyzések vannak, jellemzően több száz (idővel több ezer), ezért vannak már eleve külön táblákba mentve.
És a bejegyzéseket jelenítem meg az oldalon időrendi sorrendben.
Viszont mivel sokszor előfordult, hogy frissült az adatbázis, miközben lapozgattam a listázott bejegyzések között (egyszerre csak 4-et jelenít meg (LIMIT 4, csak azt nem másoltam be a kódrészletbe), aztán görgetés után a következő 4-et, és így tovább), ezért újra ugyanazt a bejegyzést jelenítette meg (mert megjelenítette a 4 legfrissebbet, aztán frissült a bejegyzés, frissebb bejegyzések kerültek előre, tovább görgettem, betöltötte a következő 4-et, de azok egyszer már meg lettek jelenítve a frissítés előtt, így kvázi duplán jelentek meg (nem egymás után, de ha visszagörgettem feljebb, akkor láttam)). Ezért csináltam meg így, hogy amit már egyszer megjelenített, újra nem fogja.Ha fontos az időben csökkenő rendezés, akkor én tennék egy select * from ( ) order by date desc-et az unionok köré.
Itt nekem az a lényeg, hogy az 5 táblából a lapra a bejegyzések időrendi sorrendben kerüljenek. Tehát ha a legfrissebb a table2-ben van, akkor azt jelenítse meg először. Ha a második és harmadik legfrissebb a table4-ben, akkor utána azokat. Lehet, hogy a table1-ben lévő bejegyzések csak a sokadik 4-es csoportban jelennek majd meg, mert annyival régebbi bejegyzések.Logikus teljesen, amit írsz, csak át kell gondolnom, hogy nálam miért jeleníti meg pont úgy, ahogy én akartam - ellenőriztem milliószor az időbélyegzőket is.
Köszi, hogy felhívtad rá a figyelmem, átnézem majd még egyszer.
Tehát ha az első lekérdezést nézem (ahol még nincs kizárva egy ID sem), akkor egy zárójelpár hozzáadása a megoldás, igaz? Így:
(SELECT * FROM table1UNION ALLSELECT * FROM table2UNION ALLSELECT * FROM table3UNION ALLSELECT * FROM table4UNION ALLSELECT * FROM table5)ORDER BY date DESCLIMIT 4Legalábbis elvileg, lehet, ez így hibára fut, nem tudom, csak este/holnap tudom majd kipróbálni.
Ez visszaadja a 4 legfrissebb bejegyzést, majd a következő lekérdezés már ennek a 4-nek az ID-jait kizárja, pl. így:
(SELECT * FROM table1UNION ALLSELECT * FROM table2WHERE id NOT IN (1)UNION ALLSELECT * FROM table3UNION ALLSELECT * FROM table4WHERE id NOT IN (1,2)UNION ALLSELECT * FROM table5WHERE id NOT IN (1))ORDER BY date DESCLIMIT 4Így lesz a jó?
Köszi.
-
'NOT IN' elég pazarló (legalább is az én ismereteim szerint), persze lehet, hogy a modern motorok már átalakítják kevésbé lassabbakra.
A LIKE-ok meg szerintem mindegy milyen scope-ban futnak. Simán egybe lehet rakni az összes táblát és utána szűrni:SELECT * FROM (
SELECT * FROM table1
UNION ALL
SELECT * FROM table2
UNION ALL
SELECT * FROM table3
UNION ALL
SELECT * FROM table4
UNION ALL
SELECT * FROM table5
)
WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))
ORDER BY date DESC -
nyunyu
félisten
Mi a ráknak van öt, tökegyforma táblába szétszedve az adat?
Teljesen felesleges, hacsak nincs sokmillió rekord, és időnként másik táblába archiváltok.
Gyorsan hízó logokhoz szerintem felesleges az unionnal bohóckodni, egyszerre úgyis csak egy logban akarsz keresni, hiszen nagyjából be tudod lőni, milyen dátum intervallumot akarsz vizsgálni.Meg az order by-t sem értem, mert ebben a formában csak az ötödik táblát rendezi csökkenőbe.
Először kapod az első táblát rendezetlenül, aztán a másodikat, aztán a harmadikat... végül az ötödiket rendezve.
Ha fontos az időben csökkenő rendezés, akkor én tennék egy select * from ( ) order by date desc-et az unionok köré. -
Taci
addikt
Sziasztok!
Ránéznétek kérlek, hogy ezek a lekérdezések (példák, az értékek persze folyamatosan változnak) nem "pazarlóak"-e?
Működnek tökéletesen, csak nem tudom, hogy lehet-e/kell-e optimalizálni őket.SELECT * FROM table1WHERE id NOT IN (102,103)UNION ALLSELECT * FROM table2WHERE id NOT IN (104,105,106,107,108,109,110,111,112)UNION ALLSELECT * FROM table3WHERE id NOT IN (31,32,33,34,35,36,37)UNION ALLSELECT * FROM table4WHERE id NOT IN (59,60,61,62,63)UNION ALLSELECT * FROM table5WHERE id NOT IN (21)ORDER BY date DESCA másik pedig:
SELECT * FROM table1WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))UNION ALLSELECT * FROM table2WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))UNION ALLSELECT * FROM table3WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))UNION ALLSELECT * FROM table4WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))UNION ALLSELECT * FROM table5WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%'))ORDER BY date DESCHa nem "életbevágó", nem nyúlnék hozzájuk, viszont ha jobb lenne optimalizálni (valahogy), akkor megköszönném az iránymutatást.
Köszi.
-
nyunyu
félisten
válasz
sztanozs
#4919
üzenetére
Csak hogy az Oracle szintaxis is meglegyen:
select szttorzsszam, sztnev, listagg(klnevhu, ',') within group(order by klnevhu) from szemelytorzs
left join bfkepzettsegimatrix on szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
left join kepzettseglista on bfkepzettsegimatrix.kmkepzettsegid = kepzettseglista.klid where szttorzsszam = '1234'
group by szttorzsszam, sztnev; -
Ispy
nagyúr
válasz
Diopapa
#4925
üzenetére
Hát akkor csináld amit mond, rakd be a group by-ba
![;]](//cdn.rios.hu/dl/s/v1.gif)
De a legjobb az lenne, ha az egész group by részt kiszednéd először, hogy megnézd mit is kapsz.
Sőt lehet, hogy a group by nélkül, ha megy, akkor egy subselectbe csomagolod és úgy group by-olod be.
SELECT szttorzsszam,
sztnev,
klnevhu
FROM (
SELECT szttorzsszam,
sztnev,
STUFF ((
SELECT ',' + kepzettseglista.klnevhu AS [text()]
FROM kepzettseglista
WHERE kepzettseglista.klid = bfkepzettsegimatrix.kmkepzettsegid
FOR XML PATH('')
), 1, 1, '' )
AS [klnevhu]
FROM szemelytorzs
LEFT JOIN bfkepzettsegimatrix ON szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
WHERE (szttorzsszam = '1234')
) S
GROUP BY szttorzsszam,
sztnev,
klnevhu -
Ispy
nagyúr
válasz
Diopapa
#4923
üzenetére
Nem tudom jó-e, nem tudtam tesztelni, de kb. ezt hegesztgessed.
SELECT szttorzsszam,
sztnev,
STUFF ((
SELECT ',' + kepzettseglista.klnevhu AS [text()]
FROM kepzettseglista
WHERE kepzettseglista.klid = bfkepzettsegimatrix.kmkepzettsegid
FOR XML PATH('')
), 1, 1, '' )
AS [klnevhu]
FROM szemelytorzs
LEFT JOIN bfkepzettsegimatrix ON szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
WHERE (szttorzsszam = '1234')
GROUP BY szttorzsszam,
sztnev -
-
válasz
Diopapa
#4918
üzenetére
mysql/mariadb
select szttorzsszam, sztnev, group_concat(klnevhu) from szemelytorzs
left join bfkepzettsegimatrix on szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
left join kepzettseglista on bfkepzettsegimatrix.kmkepzettsegid = kepzettseglista.klid where szttorzsszam = '1234'
group by szttorzsszam, sztnevmssql (2017+)
select szttorzsszam, sztnev, STRING_AGG(klnevhu, ',') from szemelytorzs
left join bfkepzettsegimatrix on szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
left join kepzettseglista on bfkepzettsegimatrix.kmkepzettsegid = kepzettseglista.klid where szttorzsszam = '1234'
group by szttorzsszam, sztnevpostgres
select szttorzsszam, sztnev, array_to_string(array_agg(klnevhu), ',') from szemelytorzs
left join bfkepzettsegimatrix on szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
left join kepzettseglista on bfkepzettsegimatrix.kmkepzettsegid = kepzettseglista.klid where szttorzsszam = '1234'
group by szttorzsszam, sztnev -
Diopapa
addikt
Sziasztok, kérlek segítsetek!
Van 2 táblám, az egyik egy törzsadatokat tartalmazó,
Meg egy másik:
Egyszerű lekérdezésem:
select szttorzsszam , sztnev , klnevhu from szemelytorzs
left join bfkepzettsegimatrix on szemelytorzs.szttorzsszam = bfkepzettsegimatrix.kmtorzsszam
left join kepzettseglista on bfkepzettsegimatrix.kmkepzettsegid = kepzettseglista.klid where szttorzsszam = '1234'Az eredménye:
Hogyan tudom megoldani, hogy egy név csak egyszer szerepeljen és a "klevhu" mezők egymás mögött szerepeljenek?
Előre is köszönöm!
-
#4917
sztanozs
veterán
Apollo17hu
#4915
válasz
Apollo17hu
#4915
üzenetére
Az, hogy milyen példát hozott még nem jelenti azt, hogy ez a való életben is így lesz (lehet, hogy csak nem gondolt rá)...
-
válasz
kw3v865
#4910
üzenetére
Ez már operációkutatás, nem adatbázis kérdés...
tegyük fel a következőt:
1 | 2 | 10 | 20
2 | 2 | 10 | 30
3 | 2 | 10 | 40
4 | 2 | 20 | 30
5 | 2 | 20 | 40
6 | 2 | 20 | 50
7 | 2 | 30 | 40
8 | 2 | 30 | 50
9 | 2 | 30 | 60
Ezzel a forrással milyen range-eket hozol létre és melyik melyikbe tartozna? -
kw3v865
senior tag
Sziasztok!
Ismét PostgreSQL-es téma (de gondolom más SQL-ben is hasonló lehet a megoldás). Ezúttal adott egy GROUP BY probléma, amelynek során csoportokat akarok létrehozni, kissé bonyolult feltétellel.
Adott egy tábla, melynek egyik mezője értékeket tartalmaz, ezeket kell majd szummázni (illetve más, bonyolultabb műveleteket végezni, de most igyekszem leegyszerűsíteni).
Minden egyes rekordhoz tartozik egy start és egy end érték. Ezek különbsége nem haladhatja meg a 30-at, tehát olyan rekord nincs a táblában melynél a két érték különbsége nagyobb, mint 30.
Az összevonást úgy kell végrehajtani, hogy ez a szabály továbbra is érvényes legyen, ezáltal az eredmény táblában sem lehet olyan rekord, ahol a két érték különbsége nagyobb, mint 30.
Egy oszlopban a SUM, egy startmeter (értelemszerűen a legkisebb érték az adott csoportban, a) és egy endmeter (MAX).Így néz ki az input tábla, alatta pedig az eredmény, hogy kell kinéznie:
Úgy látom ez nem egy sima GROUP BY, mivel itt komolyabb csoportosításra van szükség.
Van valami tippetek miként lehetne ezt megvalósítani?
-
Ugyan angolul, de publikáltam a blogomon a PostgreSQL 11-ről 13-ra váltás menetét
Step-by-step, mindössze 20-30 percet vesz igénybe, többször tesztelt.Upgrade PostgreSQL from 11 to 13 on CentOS 7
Hátha valakinek hasznos lesz. GitLab 14-es verziójától kezdve (ami idén Június 22.-én fog kijönni) megszűnik a PSQL 11-es verziójának támogatása.
-
nyunyu
félisten
válasz
RedHarlow
#4904
üzenetére
Fizikailag belefűzni a sorvége karakter(eke)t a stringbe?
desc=desc || chr(13) || chr(10) || 'Adat: 1200'
Feltéve, ha Windows stílusú stringekkel dolgozol, ami CR+LF (\r\n)-rel van terminálva.
Unix/linux vonalon elég lehet a chr(13) (CR, \r), mac esetén a chr(10) (LF, \n) is -
#4903
nyunyu
félisten
Apollo17hu
#4902
nyunyu
félisten
válasz
Apollo17hu
#4902
üzenetére
Ezt passzolom, nem látok bele ennyire az SQL optimalizálók lelkivilágába.
Érzésem szerint rá kéne jönnie, hogy ugyanazt akarod számoltatni az group by-nál is, így a korábban kapott eredményhalmazt használja, de meg kéne nézni egy konkrét végrehajtási tervet, hogy változik-e ha kiírod az order by-nál a case-whent, vagy ha oszlopsorszámmal hivatkozod.
-
nyunyu
félisten
És köszi a tippeket.
), 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.)
300 és 500 karakter között 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), 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?
)
Nagyon köszi a linket, áttanulmányzom! 
Új hozzászólás Aktív témák
- EarFun Air Pro 4+ – érdemi plusz
- Projektor topic
- PlayStation 5
- Házimozi belépő szinten
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- Vezetékes FEJhallgatók
- Magga: PLEX: multimédia az egész lakásban
- Ezt nézed TikTokon és YouTube-on a telefonodon
- Interactive Brokers társalgó
- Vezeték nélküli fülhallgatók
- További aktív témák...
- Dell Precision 7560 Workstation i7-11850H 32GB RAM 1TB SSD Nvidia RTX A3000 6GB 1 év garancia
- LG 55C2 - 55" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen5 CPU
- HIBÁTLAN iPhone 13 mini 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3285
- Sony PS3/PS4/PS5 és kézikonzolok Okosítása és Szoftveres szintű javítása - RÉSZLETEK A LEÍRÁSBAN
- Samsung Galaxy S21 FE / 6/128GB / Kártyafüggetlen / 12Hó Garancia
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest