Hirdetés
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- MasterDeeJay: i7 4980HQ asztali gépben (vs i7 4770)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ldave: New Game Blitz - 2025
Új hozzászólás Aktív témák
-
nyunyu
félisten
válasz
DeFranco
#4699
üzenetére
Csak tipp: felső selecthez hozzájoinolod az egyedenkénti szummát egy új oszlopba, majd ezzel az értékkel osztod lent a sum(ertek)-et?
select * from (
with egyed_osszeg as
(select egyed_azonosito,
sum(ertek) osszeg
from tabla
group by egyed_azonosito)
select t.egyed_azonosito,
t.csoport_kepzo,
t.ertek,
o.osszeg
from tabla t
join egyed_osszeg o
on t.egyed_azonosito = o.egyed_azonosito
)
pivot
( sum(ertek)/osszeg
for csoport_kepzo in ('A','B'...)
) -
DeFranco
nagyúr
Sziasztok,
Oracle SQL developert használok és az alábbi feladatot szeretném megoldani.
Adott egy pivot-olt lekérdezés, amivel lejön egy kereszttábla, adatokkal.
Példa:
SELECT * FROM
(
SELECT
[EGYED AZONOSITO],
[CSOPORT KEPZO],
[ERTEK]
FROM
[TABLA]
)
PIVOT
(
SUM([ERTEK])
FOR [CSOPORT KEPZO] IN ([A],[B],[C],[...],[Z])
)Tehát ERTEK összesített adatait CSOPORT KEPZO szerint egymás mellé pakolja minden EGYED AZONOSITO esetén.
Szeretném mellé tenni egy másik kereszttáblába azokat az indexeket, amik úgy képződnek, hogy az EGYED AZONOSITO szerint minden ERTEK-et összeadok CSOPORT KEPZO-től függetlenül és ezzel a fenti tábla megfelelő sorának minden értékét elosztom.
Példa:
Első pivot:
Béla 0,0,15,0,0,30,0,15
Második pivot:
Béla 0,0,0.25,0,0,0.5, 0,0.25
Hogyan tudom ezt megoldani?
-
#4697
RoyalFlush
őstag
Louro
#4673
RoyalFlush
őstag
Elsőre azt gondoltam, hogy az egymást követő rekordokra vonatkozó lekérdezés lefedi az esetek egészét, de ez végül téves feltételezésnek bizonyult a részemről és a Descartes-szorzatot használó megoldás több keresett találatot eredményezett. Úgyhogy bambano, tm5 köszönöm szépen mindkettőtöknek
-
nyunyu
félisten
Probléma az, hogy a WHERE után írt feltétel az globális.
Ha oda azt írja, hogy t19.ertek>19, akkor minden olyan rekordot vissza fog adni, ahol ez teljesül.
NULL értékekre definíció szerint <,=,> hasonlítás sem teljesül, emiatt kiszűri azokat, ahol csak a T20 táblában lenne jó érték, de a T19-ben nincs.LEFT/RIGHT/FULL JOINkor emiatt fokozottan figyelni kell a NULLokra.
Tehát valami ilyesmit tud csinálni, hogy
where (t19.ertek is null OR t19.ertek>19)
and ... többi feltétel. -
-
-
nyunyu
félisten
Lehet, hogy az első logikája érthetőbb lenne CTE szintaxissal:
with utolso_tankolas as
(select rendszam,
max(datum) max_datum
from tankolas t
group by rendszam)
select
t.datum,
t.rendszam,
t.km
from tankolas t
join utolso_tankolas t2
on t.rendszam = t2.rendszam
and t.datum = t2.max_datum; -
nyunyu
félisten
válasz
Petya25
#4684
üzenetére
Először le kéne válogatni rendszámonként az utolsó dátumot, majd azokhoz a rendszám-dátum párosokhoz tartozó km értéket kikeresni a táblából.
Alselect helyett joinnal:
select
t.datum,
t.rendszam,
t.km
from tankolas t
join (select rendszam,
max(datum) max_datum
from tankolas t
group by rendszam) t2
on t.rendszam = t2.rendszam
and t.datum = t2.max_datum;Vagy rendszámonként besorszámozod dátum szerint csökkenőbe, és minden rendszámhoz az első rekordot veszed:
select datum,
rendszam,
km
from (select datum,
rendszam,
km,
row_number() over (partition by rendszam order by datum desc) rn
)
where rn=1;Egyébként ha meg feltételezzük, hogy a km állás monoton növekvő (magyarul nem szokták babrálni az órát), akkor egyszerűbben is lehet, hiszen a max(datum) és a max(km) érték ugyanazon a rekordon kéne hogy legyen:
select rendszam,
max(datum) datum,
max(km) km
group by rendszam;De ilyet ne feltételezzünk, mert a valóság az, hogy ahány adatrögzítő, annyiféleképpen sikerült bevinnie az adatot az évek során.
-
user112
senior tag
Sziasztok!
Évente külön táblában (T20, T19 stb) tárolt KOD, TIPUS, ÉRTÉK adatokat szeretnék lekérni:
KOD, TIPUS, ÉRTÉK_19, ÉRTÉK_20, változás%
formában, hogy az azonos KOD és TIPUS adatok egy sorban legyenek és akkor is megjelenjen, ha csak az egyik táblában szerepel (Oracle).
Köszönöm. -
nyunyu
félisten
Egyáltalán kell egy plusz lekérdezés az Oracle specifikus from dual szintaxissal?
Nem lenne egyszerűbb egy
select nvl(count(*),0) from tablanev;[szerk:]Hmm,Oracle 11G2 amúgy is 0-t ad vissza count(*)-ra, ha nincs egy rekord se a táblában, nem NULL-t.
-
Sziasztok,
Van egy selectem ami count-ol. Tök jól is működik. Viszont előfordul olyan is, hogy nincs a selectnek eredménye. Meg tudom az csinálni valahogy hogyha nincs eredmény, akkor a visszaadott érték 0 legyen, ne pedig semmi?
Egy excel macroval futtatom a selectet, és elég zavaró a semmi :D -
#4673
Louro
őstag
RoyalFlush
#4664
Louro
őstag
válasz
RoyalFlush
#4664
üzenetére
Mondjuk már engem is érdekel a pontosítás. Csak egymást követőek a kérdésesek vagy a teljes tábla?
Egy példa:
Ebben az esetben
- ha csak az előzővel kell összehasonlítani, akkor a LEAD vagy LAG megoldás jó lehet. De 3. és 4. sor nem lesz hiba. Hisz növekszik a dátum.
- ha a teljes táblára kell nézni, azaz ha van olyan dátum a megelőző sorokban, ami kisebb, akkor az összes olyan sort adja vissza, akkor a Descartes szorzat a nyerő. A példában a legkisebb a 2020.01.01, így minden előtte levő hibás.Első esete szerintem azért nem lesz jó, mert ha kijön, hogy a 3. sorban lévő dátum kisebb, mint az előtte levő, azt lehet javíttatod. Majd újra futtathatod, amíg az összes sort rendbe nem teszik.
Ha nincs 2-300000 sor a tábla, lehet kitenném Excel-be a felhasználóknak és tennék rá egy feltételes formázást, =B2<B3, azaz ha kisebb a Dátum mező az előzőnél, akkor színezze ki nekik. A felhasználók többsége imádja a színeket.
-
Szmeby
tag
Értem, és köszönöm a választ. Én is szeretem elszeparálni egymástól a lazán kapcsolódó dolgokat. SRP FTW!
Az mondjuk valóban egy fontos kérdés, hogy mi lehetett a kérdező szándéka. Tök érdekes látni, hogy ennek hiányában két egészen eltérő megoldás is született. Az, hogy nem akarja szemmel verni, mindkét esetben teljesül. De hogy ezután mihez kezd velük... arra lehet, hogy egy harmadik megoldás lesz az ideális.
-
tm5
tag
válasz
bambano
#4670
üzenetére
Hát a lenti feladatleírás alapján ha az ID nő akkor a DATUMnak is növekvőnek kell lennie.
Tehát ha ID1 < ID2 < ID3 < ID4 < ID5... akkor DATUM1 < DATUM2 < DATUM3 < DATUM4 < DATUM5... az elvárt állapot. Ezek alapján szerintem fölösleges a DATUM5-t mondjuk a DATUM2-vel hasonlítani, elég csak DATUM4-gyel, mert nem hiszem, hogy van olyan eset, hogy kisebb lenne DATUM2-nél de nagyobb mint DATUM4.
Szóval igen, ez csak egymás utáni párokat vizsgál, de szerintem ez elég.
Szmeby:
Én szeretem használni a WITH-et, mert jobban elszeparálja az egyes logikákat egymástól. Jelen esetben akkor a teljes LEAD-es részt bele kellett volna tenni a WHERE-be is, mert ugye ugyanazon queryn belül nem tudod a SELECT-ben megadott aliasokat a WHERE feltételben használni. Szóval így szebb és érthetőbb.
A next_id azért kellett, mert így látod, hogy melyik két egymást követ ID-nál van gond a dátumokkal. De elhagyható...Szerintem ez jóval gyorsabb (vagy csak "olcsóbb" ha nem nagy a tábla), mint egy Descartes szorzat. Én napi szinten használok analitikus SQL kifejezéseket millió soros táblákon Oracle-ben és szerintem nagyon jól optimalizált a futtató mögötte. Tény, hogy ebbe az Exadata is besegít.
-
szerintem ez a megoldás nem a kérdésre ad választ, mert ez csak azt mondja meg, ha két egymásutáni rekordnál rossz a dátum sorrendje, azt nem, hogy két tetszőleges rekordnál is az.
tehát ha van egy id=300, datum='2019-07-30' rekordod, azt a te megoldásod nem találja meg, az enyém igen. a kérdés, hogy a kérdező mit akart kérdezni
-
#4669
Szmeby
tag
Apollo17hu
#4668
Szmeby
tag
válasz
Apollo17hu
#4668
üzenetére
Köszi Apollo! Fantasztikus ez az Oracle.
És tm5 azért csomagolta egy WITH-be, mert WHERE mögött ezek az analitikus cuccok nem használhatók, csak projekcióban (vagy hogy is hívják a from előtti részt)?
A next_id kiszámításának van valami különleges oka, vagy az amúgy elhagyható? Én feleslegesnek érzem az aktuális probléma szempontjából. Hacsak az oracle belső mechanizmusai ezt mégis megkövetelik valami mágikus okból.
Ez a megoldás amúgy a Descartes szorzathoz képest milyen előnyöket nyújt? Gyorsabb? Kíméli a memóriát? Elegánsabb?
A paraszti eszem azt súgja, hogy nem igazán lehet gyorsabb, hiszen ígyis úgyis kétszer szelektál a táblából, csak más sorrendben teszi a folyamat során. Hacsaknem attól ér el gyorsabb működést, hogy a nyers adatok diszken való rendezettségének köszönhetően a vinyó kevesebb fejmozgással is végre tudja hajtani a lekérdezést egy nagy adathalmazon. Bááár, azzal, hogy az eredeti halmazon nincs orderby, a lead függvény meg sorrendezett halmazon operál, még ez sem feltétlenül biztos. Asszem elkalandoztam.
-
#4668
Apollo17hu
őstag
Szmeby
#4667
Apollo17hu
őstag
A LEAD függvénnyel olyan oszlop hozható létre, ami egy meglévő mező csoportosított/sorbarendezett értékeit eltolja.
tm5 megoldásában a halmaz nincs csoportosítva, csak ID alapján sorbarendezve. E szerint az ID és a DATUM mezőket egy rekorddal eltolva képzi meg a next_id és next_datum oszlopokat.Alapértelmezettként az eltolás mértéke 1, ekkor elhagyható.
A LEAD-hez hasonló még a LAG függvény, ahol az eltolás "ellenkező" irányba történik. -
#4666
tm5
tag
RoyalFlush
#4664
tm5
tag
válasz
RoyalFlush
#4664
üzenetére
Analitikus függvényekkel is neki lehet esni és akkor nem kell descartes szorzat:
WITH src AS (
SELECT
id
, datum
, LEAD(id) OVER ( ORDER BY ID ) next_id
, LEAD(datum) OVER ( ORDER BY ID ) next_datum
FROM datumok)
SELECT *
FROM src
WHERE datum > next_datum -
#4665
bambano
titán
RoyalFlush
#4664
válasz
RoyalFlush
#4664
üzenetére
valahogy így:
select t1.*,t2.* from datumok t1, datumok t2 where t1.id>t2.id and t1.datum<t2.datumfejből írtam, nem biztos, hogy szintaktikailag helyes.
-
#4664
RoyalFlush
őstag
RoyalFlush
őstag
Sziasztok!
A segítségeteket szeretném kérni (Oracle PL/SQL).
Van egy tábla (DATUMOK) az alábbi oszlopokkal:
ID
DATUMAzt szeretném lekérdezni, hogy mely rekordoknál fordul az elő, hogy kisebb ID-val, de nagyobb DATUM értékkel szerepel, mint egy másik.
Példa:
ID DATUM100 2020-01-01200 2019-06-30Hogyan lehetséges ezt lekérdezni, hogy ne szemmel veréssel kelljen összehasonlítgatni, vannak e ilyen sorok a táblában és melyek?
Köszönöm!
-
nyunyu
félisten
Akár alselectet is lehetett volna írni:
SELECT *
FROM items
WHERE type=477
AND status='OPEN'
AND id in (SELECT id
FROM items
GROUP BY id
HAVING COUNT(*) = 1)Elvileg ez ekvivalens az előző, joinolt megoldással.
#4660: Szerintem a kérdés direkt van ilyen egyszerűre fogalmazva, hogy meg lehessen oldani subquery meg analitikus függvény nélkül.
Szerintem meg észre kéne venni, hogy ez a feladat két lépésből áll, először leválogatni az egyelemű tételeket, majd azokon szűrni.
Ha egy selectben szűrsz és számolsz, akkor fals eredményt fogsz kapni, mivel a szűrt eredményhalmazt fogja megszámolni, nem a teljes táblát.
(Először a WHERE értékelődik ki, és csak utána a HAVING)-> vagy alselect vagy join kell.
-
bpx
őstag
A kérdés az volt, hogy azok a sorok kellenek amelyek ID-ja csak egyszer szerepel a táblában, továbbá igaz rájuk, hogy status = open, type = 477.
Nálad a status = open, type = 477 szűrés az aggregráció előtt történik, mert az a WHERE-ben van, nem a HAVING-ben.
Emiatt ha pl. így néz ki a tábla, akkor az eredményedbe mindkettő sor bekerül:
id | status | type
--------|--------|------
1 | open | 477
1 | closed | 476Erre nem teljesül az, hogy az ID csak egyszer szerepel, hiszen 2 sorban is ott van, és mivel csak az ID alapján történik a self join, visszadja az ID-hoz tartozó összes többi sort is, amelyekre a status = open, type = 477 nem teljesül.
A min(status) meg min(type) részhez annyi, hogy a having count(*) miatt eleve csak az 1 tagú csoportokat vizsgáljuk, ahova mindegy, hogy min vagy max vagy más csoport függvényt írok, de valamit muszáj, hogy megegye az aggregráció + having. A havingben ott van utána még a számunkra szükséges szűrés, ez az aggregáció után történik, és az 1 elemű csoportokból csak a nekünk szükségeseket hagyja meg.
Szerintem a kérdés direkt van ilyen egyszerűre fogalmazva, hogy meg lehessen oldani subquery meg analitikus függvény nélkül.
-
-
RedHarlow
aktív tag
Sziasztok, kezdő vagyok SQL terén, már 2-3 órát beleöltem a következő feladatba, esetleg tudna segíteni benne valaki?
Az items táblából szeretném lekérni az olyan sorokat aminek az ID-je csak 1x szerepel a táblában majd a kapott tömbből szeretném ha ez a két feltétel teljesülne: status = open, type = 477.
Előre is nagyon szépen köszönöm a segítséget.
-
-
nyunyu
félisten
válasz
Szancsó
#4646
üzenetére
Én kiemelném egy CTEbe az A, B összege oszlopokat, és kapna egy sorszámot összeg szerint csökkenő sorrendben, majd következő lépésben ebből válogatnám le a sorszám<=5-öt ("top 5"), és hozzáunióznám a szumma(B összeg)-et, ahol sorszám>5.
Így az eredeti táblát csak egyszer kell végigolvasni, második lépésben uniót képző 2 select már a memóriában lévő párszáz-ezer soros aggregátumból dolgozik, minimális többletköltséggel.
Valahogy így:
with summa as (
select a,
sum(b) sum_b,
row_number() over (partition by a order by sum(b) desc) rn
from tabla5
group by a),
top5_summa as (
select a,
sum_b,
rn
from summa
where rn<=5
union
select 'Többi' as a,
sum(sum_b) as sum_b,
6 as rn
from summa
where rn>5)
select a,
sum_b
from top5_summa
order by rn;Nem tudom, Firebird ismeri-e ezt a szintaxist, SQL Server kb. 2005 óta igen, meg az Oracle 11 alatt is működik.
-
Szancsó
aktív tag
Sziasztok!
Top lekérdezéssel kapcsolatban lenne kérdésem: arra van módszer, hogy egy lekérdezésen belül visszakapjam az összesített és rendezett halmazból az első x elemet, valamint az ezeken kívüli rekordok összesített értékét is egy plusz sorban?
Tehát pl. van egy táblám [A], [B] oszlopokkal és 1000 sorral, amikben az [A] 50 féle értéket vehet fel, a [B] pedig az aggregálandó mező. Ebből kellene pl. a TOP 5, de úgy, hogy gyakorlatilag 6 rekordot kapjak vissza: az utolsóban annak a 45 féle [A] értéknek az összesenjével, ami egyébként nem fért bele a topba.
A nagyságrend elégé változó, de az [A] értékeket tekintve több 10e simán előfordulhat és a top is kb. tetszőleges, ezért kerülném a kétlépcsős megoldást (ha lehet).
Firebird 2.5 és 3, MsSQL, Oracle megoldás érdekelne. -
-
-
kem
addikt
Sziasztok!
Szeretnek importalni egy SQL dumpot AWS Aurora-MyAQL DB-be:
source dump: 5.7.26
linux agent: mysql Ver 14.14 Distrib 5.7.30
target rds: 5.7.mysql_aurora.2.08.1Amikor importalni probalom, ezt a hibauzenetet kaupjuk:
ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'COMMENT='Stored indicator calculations'' at line 14
A dump erre vonatkozo szakasza:-- MySQL dump 10.13 Distrib 5.7.26, for Linux (x86_64)---- Host: localhost Database: <removed>-- -------------------------------------------------------- Server version 5.7.26-enterprise-commercial-advanced-log/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;/*!40101 SET NAMES utf8 */;/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;/*!40103 SET TIME_ZONE='+00:00' */;/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;---- Table structure for table `<removed>`--DROP TABLE IF EXISTS `<removed>`;/*!40101 SET @saved_cs_client = @@character_set_client */;/*!40101 SET character_set_client = utf8 */;CREATE TABLE `<removed>` (`id` bigint(10) NOT NULL AUTO_INCREMENT,`starttime` bigint(10) NOT NULL,`endtime` bigint(10) NOT NULL,`contextid` bigint(10) NOT NULL,`sampleorigin` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',`sampleid` bigint(10) NOT NULL,`indicator` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',`value` decimal(10,2) DEFAULT NULL,`timecreated` bigint(10) NOT NULL,PRIMARY KEY (`id`),KEY `<removed>_staendcon_ix` (`starttime`,`endtime`,`contextid`),KEY `<removed>_con_ix` (`contextid`)) ENGINE=InnoDB AUTO_INCREMENT=54076 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=COMPRESSED COMMENT='Stored indicator calculations';/*!40101 SET character_set_client = @saved_cs_client */;Ez pedig a parancs amivel probaljuk importalni.
Korabban a heten mukodott a dump elozo verziojaval ami 10x ekkora volt mert tele volt logokkal.cat dbdump.sql | sed 's/ROW_FORMAT=COMPRESSED/ROW_FORMAT=/g' | sed 's/user_b/user_a/g' | time mysql -p -h aurora-mysql-cluster.cluster-<removed>.eu-east-x.rds.amazonaws.com -u user_a dbname --max-allowed-packet=1073741824A DBt pedig ezzel krealtam:
CREATE DATABASE dbname CHARACTER SET utf8 COLLATE utf8_unicode_ci;Probalunk rajonni mi lehet a baj, de minden jonak tunik szintaktikailag.
A dump 26GB.Elore is koszonok barmilyen otletet.
szerk: elnezesd de akarhogy szerkesztem szanaszet hullik a formazas
-
OldBoyDev
újonc
Jó estét, szervusztok!
Van két adatbázisom (MS SQL platform), az egyik egy helyi SQL szerveren, a másik Azure felhőben. Mindkét adatbázist látom az SQL Management Studioban. Hogy tudok összekapcsolni (JOIN) két táblát, ha az egyik a local serveren van, a másik meg a felhőben?
-
valaki tudja véletlenül, hogy xml adattípusból hogyan kell a root elemet kiszedni xpath-szal? esetleg ugyanezt konkrétan postgresql-ben?
kösz.
-
bpx
őstag
Egy indexet több módon lehet használni.
Az oszlop1 like 'valami%' szűréshez megy az index range scan az oszlop1-en levő indexen. Ez hatékonyan működik.
Az oszlop1 like '%valami%' szűréshez szintén használható az oszlop1-en levő index, csak az már nem index range scan, hanem index fast full scan lesz, ahol az adatbázis a teljes indexet végigolvassa random sorrendben.
Az oszlop1 like '%valami%' szűréshez ha még egy order by oszlop1 is van, akkor pedig index full scan is használható, ahol az adatbázis a teljes indexet végigolvassa, de a fa struktúrát bejárva, rendezett sorrendben.
Tehát nem, nem lesz mindig full table scan, mert a 300 oszlopot tartalmazó táblára történő full scan helyett még mindig gyorsabb a csak 1 oszlopot tartalmazó és ezáltal sokkal kisebb méretű indexen a full scan.
De az utóbbi 2 már nem hatékony és ha nagy mennyiségű adaton kell szöveges keresést végrehajtani, akkor a like '%valami%' helyett ott van az Oracle Text a saját indexeivel és függvényeivel, meg a többi adatbázisnál is a text alapú indexek és keresések. -
nyunyu
félisten
tábla1.oszlop1 LIKE '%valami%' miatt mindig full table scan lesz, nem tud semmilyen indexet használni a joinhoz.
Míg ha tábla1.oszlop1 LIKE 'valami%' -t írnál (vagyis a string elején keresel, nem közben), akkor a tábla1.oszlop1-re tett index használható lenne, és nem kellene mindig végigolvasnia az egész táblát.
-
Louro
őstag
Ezt nem is vitatom, meg lehet én is írtam ilyet. Kell a pénz. Beszállító max az elején naív, hogy minőségi terméket, szolgáltatást készíthet, de pár megrendelés után valószínűleg rájön, hogy elég olyat felvenni, ami tud valami karistolni. Nem kell, hogy elhivatott legyen. Majd kicsit feljebb tolják a projekt közben az "ajánlott gépigény" részt.
Amúgy picit ON is legyek. De nem vitaindítónak szánom, hátha kiesik valami tanulság másoknak (is).
Egyik kolléga már egy hete szenvedett valamivel. Egyszer megírta a kódot és kb. mindig ugyanazt futtatta, de 12+ óra utána megszakadt a kapcsolat (távmunka). Remélte, hogy hátha valaki más is futtat valami számításigényes feladatot és elcsíphet egy nyugodtabb időszakot.
Megnézve a kódot, kicsit átírva 38 másodpercre le lett faragva a futási idő.
Három, relatíve kicsi tábla (300e rekord) tábla lett összekapcsolva.
De a gondot az okozhatta, hogy az ON feltétel után olyan komplex feltétel volt, hogy ledobtam az ékszíjat. Valami ilyesmi lehetett:SELECT fejléc
FROM tábla1
INNER JOIN tábla2
ON (
tábla1.oszlop1 LIKE '%valami%'
OR
tábla1.oszlop2 >= tábla2.oszlop1
OR
(tábla1.oszlop3 IN (SELECT tábla3.oszlop1
FROM tábla3
WHERE oszlop2 > tábla2.oszlop4)
AND .....))Igazából annyit módosítottam a kiraktam a feltételeket külön oszlopokba CASE WHEN-ekkel, majd utána végeztem el a kötéseket. Táblakötésbe LIKE és ennyi feltétel a korábbi tapasztalataim alapján nem túl hatékony. Bár query plan-t a kollégák nem szokták nézni, pedig sokszor hasznos lenne.
+1: Sajnos sokszor látok olyat is, hogy fejlécben van tábla úgy bekötve, hogy ott is van még egy tábla a SUBSELECT-en belül. Például
SELECT
(SELECT oszlop1 FROM tábla2 WHERE tábla2.oszlop2 = (SELECT MAX(oszlop2) FROM tábla2)) c
FROM tábla1 -
Szmeby
tag
Ó, én nem hibáztatom, biztos vagyok benne, hogy elhangzottak. Mindig elhangzanak.
Egy ideális világban ez úgy működne, hogy a beszállító szépen feláll az asztaltól és közli, hogy van egy minőségi szint, amihez már nem hajlandó adni a nevét, a megrendelő meg hajára kenheti az "igazát". Ha a megrendelő akkora polihisztor, hogy szakmai érveket vétóz meg (vagy eleve nem is egyeztet, csak utasít), akkor miért fordult a beszállítóhoz eleve. Egy tucat majom is tud pötyögni utasítás alapján, nem kell ehhez szakember.
Nyilván olyan szerződést kell kötni az elején, ami megengedi a minőséghez való ragaszkodást és annak nem teljesülésekor az elsétálást. Kár, hogy ritka az a beszállító, aki fontosnak tart ilyesmit belefoglalni a szerződésébe. Másrészről meg ott bukik meg a csipkerózsika történetem, hogy kell a pénz, etetni kell az alkalmazottakat, így a beszállító inkább nyel egyet, görbít a gerincén még egy kicsit, és azt mondja: "jól van".
Ami engem alapvetően bosszant ebben a viselkedésben, hogy mindkét résztvevő elhiszi, hogy ettől lesz jobb a világ. És értetlenül állnak például azon probléma előtt, hogy ó, hát milyen nagy a fluktuáció! Majd jönnek a menedzsment és hr tanácsadók, akik tudják a tuti receptet a fluktuáció csökkentésére. De valahogy nem sikerül. Mert a résztvevők még mindig azt hiszik, hogy valami leküzdhetetlen külső erő arra kényszeríti őket, hogy megalkudjanak és minden szakmai érvet nélkülöző utasítást egy megcáfolhatatlan törvényként fogjanak fel: "A magasságos megrendelő kinyilatkoztatott. Mégis legyen skálázható a rendszer, amit a jövő héten adunk át. A könyörületes megrendelő hozzátevé: a határidő 5 nappal bővülhet, ha kell. A megrendelő elvárja, hogy legyen olcsó. Dologra! Ámen."
Majd a fél-2 éves csúszást követően: "A mindenható megrendelő nagyon örül, hogy VÉGRE elkészült a rendszer. De csak akkor lesz elégedett a munkával, ha ezt a néhány frissen kitalált módosítást még ingyen beletesszük. Akkor majd boldog lesz, de azért érezzük egy kicsit magunkat szarul, amiért ilyen kontár munkát végeztünk, és ilyen sokáig tartott. De azért örülünk, hogy az áldott és kegyelmes megrendelő eltekintett a kötbér fenyegető suhintásától igénytelen munkánk ellenére is."
Komolyan, ha nem lettem volna (leginkább elszenvedő) részese ezeknek a játszmáknak, csak röhögtem volna ezen a bohózaton.
Minden szereplőnek megvan a helye, tökéletesen összeállt az ökoszisztéma. Egy szociológiai aranybánya. Nem is értem, mit ágálok ellene. -
Louro
őstag
Igazán "minőségi" megoldás az lett volna, ha készül egy dictionary arra, hogy táblanév-oszlopnév-oracle táblanév-oracle oszlopnév
A szabványok jók és hasznosak, de azért néha nem árt frissíteni azokat.
@Szmeby: Szerintem a beszállítókat nem hibáztathatjuk, mert lehet elhangzottak ellenérvek. De a megrendelőnek/ügyfélnek mindig igaza van. Az se igaz, hogy minőségi cég nem végez kontár munkát. Van az a pénz.
Nálunk - pénzintézet - szintén az évek az alatt olyan igények születtek, hogy már csoda, hogy működik a rendszer. Mindig kértek valamit. Félig leszállították, mert gyorsan kellett valami. De a végét már nem rendelték meg, mert addig volt rá működő workflow. És az igények is olyanok .... . Régiek közül persze már szinte senki sincs. Szóval, ha kérdés merül fel, szép kutató munka.
-
Szmeby
tag
És gondolom, a projektben résztvevő összes cég azt állítja magáról, hogy csak minőségi szoftvert adnak ki a kezükből, a szakmai kiválóság az elsődleges.
Szerintem amúgy nem szar a terv, csak a tervező bizonyára elfelejtette, hogy a munkája nem ér véget a Generate gomb megnyomásával. A többi résztvevő meg nem volt elég tökös visszadobni a félkész produktumot. Pénz van, idő nincs, nyilván a gányolás felé húz ezek után minden résztvevő szíve. Nem szar ez, hanem kihívásokkal tűzdelt. Azt meg minden fejlesztő szereti, sokan a cv-be is beírják, a kihívás fontos.
(Sosem értettem, miért nem illik megosztani a nyilvánvaló ostobaságokat elkövető (jogi) személyek / projektek nevét. Mások okulására és tájékoztatására, hogy "ide ne gyertek dolgozni, ha nem akartok inkompetens, egyeztetésre képtelen egyedekkel együtt dolgozni". Mindig csak a cukormáz látszik. Pedig hibázni jó dolog, de azt nem beismerni totális káoszba vezet. És kinek van kedve káoszban létezni? Habár biztos akad olyan is, de én nem tartozom közéjük.)
-
nyunyu
félisten
Állami hivatal, napjainkban futó pármilliárdos IT tender.
Valamelyik nagyokos kitalálta, hogy Enterprise Architectben jól lemodellezi az egész rendszert, és megrajzolt egy olyan infrastruktúrát és adatmodellt, aminek az egyik fele felesleges, másik fele meg használhatatlan.
Hivatal IT osztálya persze ellenkezett, hogy ez így megvalósíthatatlan, kivitelezhetetlen, de hát nem ők voltak a döntéshozói szerepkörben, így el lett fogadva.
Megvalósítani meg úgyis a beszállítóknak kell...A hivatalnak van saját sokoldalas fejlesztési standardja, ami előírja a beszédes nevek használatát, minden objektumnak kell legyen egy _id végű egyedi kulcsa, minden mezőnév a táblanévvel kezdődik, stb.
Ezektől eltérni nem lehet, mert deploy előtti ellenőrzésen fennakad a kód, nem telepítik, ha valamelyik követelménynek nem felel meg.Lényeg: EAban szereplő adatmodellből generálják az objektumokat létrehozó szkripteket.
Probléma azzal még nincs, hogy a beszedes_elso_tablanev_elso_mezoje túl hosszú lenne, hanem azzal, hogy a külső kulcsok neve táblanév1_táblanév2_id alakú, illetve az N:M relációk leírásához szükséges táblák neve is konkatenálódik: táblanév1_táblanév2.
Így a benne lévő táblanév1_mezőre visszamutató mező neve elso_tabla_neve_masodik_tabla_neve_elso_tabla_neve_mezo_neve lesz.Ennek persze az lett az eredménye, hogy az EAból generált szkripteket a meglevő Oracle 12.1 rendszerük nem bírta lefuttatni, mert nem fértek bele a 30 karakteres tábla és oszlopnév limitjébe.
Főnököm felvetette, hogy akkor leimplementáljuk mi az adatmodellt, értelmesen rövidített táblanevekkel.
Na azt nem lehet, mert akkor nem felelünk meg az EAban leírt terveknek.Jó, akkor módosítsátok az EAban lévő adatmodellt úgy, hogy a konkatenált nevek is beleférjenek a 30 karakterbe.
Nem lehet, túl sok munka, meg már a projekt többi részéhez is hozzá kéne nyúlni.Harmadik opció?
DB upgrade, de annak jelentős szoftverlicensz vonzata van.Azóta a projekt alatt Oracle 19 dübörög, mivel annak a költségét egyszerűbb volt átverekedni az ilyen-olyan bizottságon, mint a szent és sérthetetlen (hetente ötször változó) haditervet módosítsák, mert az utóbbi annak a beismerése lett volna, hogy a terv alapból szar.
Akarom mondani a DB frissítés kisebb projekt kockázattal járt, mint a tervet módosítani.
-
-
whYz
őstag
Sziasztok
Van egy tablam par VIRTUAL GENERATED oszloppal. Amikor mysqldump-al csinalok egy backupot akkor ezeknek az oszlopoknak az erteke is belekerul a backupba. Amikor probalom visszaallitani a backupot akkor viszont errort dob a mysql szerver, mivel virtual oszlopba nem lehet insertelni. Mi lehet a megoldas? A szerver verzio 5.7.18.
-
nyunyu
félisten
Pár éve az egyik mobilszolgáltató adattárházának betöltő jobjait kellett géppel feldolgoznom, ott láttam mindenféle cifra tördelést, meg extrém szintaxist a huszonéve toldozott kódban.*
Mostani melóhelyen is látom a kollégák kódolási stílusa közti különbségeket:
- kulcsszavak kis vagy nagybetűvel (select vs SELECT)
- hány szóközt használ behúzásra 2? 3?
- egy oszlopba rendezi-e a mezőneveket, aliasokat, kommenteket, vagy ahogy esik, úgy puffan
- hova teszi a vesszőt felsorolásnál:
a,
b
vagy
a
, b
(utóbbit nem szeretem, mert ronda, de könnyebb --szal kikommentezni, ha nem kell a második sor!)
- használ-e vessző után szóközt
- használ-e az egyenlőségjel, kacsacsőr körül szóközt (a=b vs a = b)
- van aki minden WHERE alatti sorba 1=2 AND-ot ír (így nem tud véletlenül elindítva lefutni a kód), aztán ha véglegessé vált a query, csak akkor kommentezi vagy törli ki.Nekem mindegy, amíg legalább annyira tördelve van, hogy el lehessen olvasni.
*: UPDATE a SET mezo=b.mezo2 WHERE a.id=b.id; megfejtését kérném OLVASHATÓAN, SQL:2003 szintaxissal leírni a válaszokban.
-
nyunyu
félisten
válasz
kw3v865
#4617
üzenetére
Ha az a cél, hogy egy külső alkalmazás paraméterezetten hívjon egy eljárást/függvényt, akkor nem tudod refcursorral visszaadni a szűrt halmazt?
Legalábbis mi Oracle 11g alapon így szoktuk visszaadni az adatokat:
procedure get_order_status(p_group_id number, p_posting_id number, p_id number, p_order_num varchar2, c out sys_refcursor) is
begin
open c for
select
i.group_id,
i.posting_id,
i.id,
i.order_num,
o.status as status,
to_char(o.status_dt,'yyyy-mm-dd hh24:mi:ss') as status_ts
from input i
left join s_order o
on o.order_num= i.order_num
where i.id = p_id
or i.group_id = p_group_id
or i.posting_id = p_posting_id
or i.order_num = p_order_num;
end;Aztán Javaban fetchelik a kurzort.
-
kw3v865
senior tag
Üdv!
PostgreSQL 10-ben egy függvényt írok, melyben szeretnék létrehozni egy view-t. A problémám az, hogy nem tudok a view létrehozásakor változót használni.
Tehát példuál a WHERE feltételnél: a "x BETWEEN valtozo1 AND valtozo2" rész problémás. Azt írja hibaként, hogy column "valtozo1" does not exist. Ha a select ugyanez, de nem view-t hozok létre, hanem táblát, akkor tökéletesen működik.
Van erre valami megoldás? Vagy tényleg nem lehet PostgreSQL függvényben lévő VIEW létrehozásakor változóra hivatkozni? -
nyunyu
félisten
Közben találtam egy másik megoldást, ami nem a JOINnál szűr, hanem CASE WHEN-ekkel pakolja külön oszlopokba az egyes tételeket:
SELECT p.projectName 'Project Name',
SUM(CASE WHEN pc.costCategory='Cost category1' THEN pc.cost ELSE 0 END) 'Cost category1',
SUM(CASE WHEN pc.costCategory='Cost category2' THEN pc.cost ELSE 0 END) 'Cost category2',
SUM(CASE WHEN pc.costCategory='Cost category3' THEN pc.cost ELSE 0 END) 'Cost category3',
SUM(CASE WHEN pc.costCategory='Cost category4' THEN pc.cost ELSE 0 END) 'Cost category4'
FROM Project p
LEFT JOIN ProjectCost pc
ON pc.projectID=p.projectID
GROUP BY p.projectName
ORDER BY p.projectName;De ez sem sokkal olvashatóbb
Jut eszembe, hasonló példával szívatott a mostani főnököm 3 éve állásinterjún.
Aztán nemsokkal később belebotlottam kolléga kódjába, ami 10 attribútum nevét és értékét feszíti ki egy termék sorra ugyanígy
Azóta sem mertem átírni PIVOTra. -
nyunyu
félisten
Ez így nem jó, mivel ő az egyes costCategory alá tartozó tételek összegét külön-külön oszlopban szeretné látni.
Meg lehet csinálni PIVOT() nélkül is, oszloponként külön JOINnal:
SELECT p.projectName 'Project Name',
SUM(pc1.cost) 'Cost category1',
SUM(pc2.cost) 'Cost category2',
SUM(pc3.cost) 'Cost category3',
SUM(pc4.cost) 'Cost category4'
FROM Project p
LEFT JOIN ProjectCost pc1
ON pc1.projectID=p.projectID
AND pc1.costCategory='Cost category1'
LEFT JOIN ProjectCost pc2
ON pc2.projectID=p.projectID
AND pc2.costCategory='Cost category2'
LEFT JOIN ProjectCost pc3
ON pc3.projectID=p.projectID
AND pc3.costCategory='Cost category3'
LEFT JOIN ProjectCost pc4
ON pc4.projectID=p.projectID
AND pc4.costCategory='Cost category4'
GROUP BY p.projectName
ORDER BY p.projectName;Itt az egyes JOINoknál szűröm a costCategory értékét, hogy az adott oszlopban melyik értékhez tartozó tételek látszanak (amiket aztán szummázunk).
PIVOT()-tal rövidebben, tömörebben lehet ugyanezt megcsinálni, viszont a mit írjak a FOR és IN részekhez megértése elsőre nehéz lehet.
-
nyunyu
félisten
válasz
OldBoyDev
#4610
üzenetére
Sorok oszlopokká forgatásához a PIVOT függvény kell, de azt nem minden DB kezelő ismeri.
Szintaxisa valahogy így néz ki:
SELECT p.projectName, pc.costCategory, pc.cost
FROM Project p
LEFT JOIN ProjectCost pc
ON pc.projectID=p.projectID
PIVOT(
SUM(pc.cost) sum
FOR(pc.costCategory)
IN('Cost category1', 'Cost category2', 'Cost category3', 'Cost category4')
)
ORDER BY p.projectName;Gyakorlatilag a FOR-nál megadott costCategory mező értékkészletét válogatja szét, és csinál belőlük új oszlopokat az IN-nél megadott sorrendben, és ezekbe az oszlopokba teszi a FOR előtti oszlopfüggvény értékét.
PIVOT()-on belül sehol nem említett oszlopok (projectName) pedig maradnak úgy ahogy van.
-
Louro
őstag
válasz
OldBoyDev
#4610
üzenetére
SELECT
Project.ProjectName AS 'Project Name',
cost.CostCategory1 AS 'Cost category1',
cost.CostCategory2 AS 'Cost category2'
FROM Project
INNER JOIN ProjectCost
ON Project.projectID = ProjectCost.projectIDHa egy projektnek több költsége is lehet, akkor....
SELECT
Project.ProjectName AS 'Project Name',
SUM(cost.CostCategory1) AS 'Cost category1',
SUM(cost.CostCategory2) AS 'Cost category2'
FROM Project
INNER JOIN ProjectCost
ON Project.projectID = ProjectCost.projectID
GROUP BY
Project.ProjectName -
OldBoyDev
újonc
Sziasztok, segítséget szeretnék kérni:
Van két táblám:
Project tábla
projectID
projectName
ProjectCost tábla
projectID
costCategory
cost
Hogy tudok ebből egy olyan lekérdezést készíteni, ahol a project neve mellett felsorolásra kerülnek (külön oszlopokban) a kategóriánkénti költségek.
Fontos, hogy egy projecthez több azonos kategóriájú költség sor is tartozhat, ezek összegének kéne szerepelni a lekérdezésben. -
Louro
őstag
Kicsit olyan ez, hogy mindkettő jó a feladatok nagy részére (, gondolok itt arra, hogy a rollup-ra pl. egy kezemen meg tudom számolni, hogy mennyiszer volt szükségem). De pl. a senior analyst kollégával nem bírom megérttetni, hogy miért felesleges Excel-ben pivotálni, miért nem bízza az erősebb SQL szerverre. Persze elbírja az Excel, csak kicsit lassabb és a felhasználói élmény csorbul.
Úgy látom bőven van mit tanulnom még. De ez jó, mert izgalmas terület
-
martonx
veterán
válasz
bambano
#4607
üzenetére
Viszont nem csak postgresql van a világon (ami egyébként tényleg nem rossz). Data Science-ként sokszor nem is igazi sql-ből jönnek az adatok (lehet nosql, vagy data lake vagy bármi), azaz kell egy nyelv az sql-en kívül, amivel egységesen meg lehet valósítani a statisztikákat, elemzéseket.
-
válasz
martonx
#4606
üzenetére
egyetértek, nincs mit magyarázni, a postgresql legalább annyit vagy többet tud, mint ez a pandas. mondjuk ez így csak a statisztikai funkciókra igaz, mert ha melléteszed például a geometriai funkcióit is, akkor a python a fasorban sincs a postgresql-hez képest.
az utóbbi időben az a vélemény alakult ki bennem a postgresql-ről, hogy a legjobb, ha hagyod az adatbáziskezelőt dolgozni.
-
martonx
veterán
válasz
bambano
#4603
üzenetére
hja, most nézem MSSQL is tud, a 2017-es verzió óta, csak valami fura okból PERCENTILE_DISC-nek hívják. Mindenesetre csak egy példát akartam hozni, hogy az SQL analitikus függvényei erősen korlátosak, próbálj meg ilyen-olyan eloszlásokat számolni velük, vonalakat illeszteni, azok meredekségét figyelni stb...
-
tm5
tag
válasz
bambano
#4600
üzenetére
Ez teljesen igaz és azt volt az első dolgom, hogy körbenézzek a cégnél, hogy milyen "dobozos" system monitoring cuccok vannak már beüzemelve(Grafana, ELK, stb.) , hogy ne az n+1-et telepítsem. Viszont egyik sem arra lett kitalálva, hogy azt monitorozza amit nekem kell.
Egy tesztelő kolléga már össze is rakott valamit regression teszt gyanánt pythonban.
Na ez megtetszett nekem és én is lejutottam oda, hogy akarok csinálni egy dashboardot a cuccaimnak. Na ebből lett az idei smart goal-om. Ha multinál dolgozol akkor érted, hogy mire gondolok.
Igen, DIY lesz, de mértékkel, mert az üzleti logikára akarok fókuszálni és nem az infrastruktúrára. De néha össze kell koszolni a kezünket, ha tanulni akarunk.
Köszönöm szépen a segítséget 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Akciós kisWorkstation! Dell Precision 3570 i7-1255U 4.7GHz / 32GB / 1000GB / Quadro T550 4GB FHD 15"
- Asus Zenbook 13 laptop Oled kijelző!
- Keresünk iPhone 13/13 Mini/13 Pro/13 Pro Max
- Microsoft Surface Laptop 4 13.5" Ryzen 5 4680U 6magos! 16GB 512GB 1 év garancia
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: Laptopszaki Kft.
Város: Budapest