- Külföldi prepaid SIM-ek itthon
- Huawei Watch Fit 5 Pro - jó forma
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Bemutatkozott az iQOO első T-szériása
- Kreatív előzetesen az Xperia 1 VIII
- Ismerős lehet az iQOO Pad6 Pro
- Apple Watch
- Poco F8 Ultra – forrónaci
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy A72 - kicsit király
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- bullseye: Clickbait szülinapi sorsolás II - még drágább a clickbaited
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: XIAOMI Smart Air Purifier 4 Compact EU - légtisztító újabb okoseszköz a lakásban
Új hozzászólás Aktív témák
-
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?
-
-
RoyalFlush
őstag
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.
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
-
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. -
-
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.
-
-
Nekem így nem akar működni.
de ha a COUNT után nem csillagot, hanem a táblát írom, így elhagyhatom a Group-ot a végéről, és így működik is rendesen
Köszönöm szépen a segítséget szívesen.
úgy tudod azt futtatni, hogy beteszed egy fiktív lekérdezésbe:
select
NVL(
(select count(ID) from TABLANEV)
, 0) as OSZLOPNEV
from dual;ezt kihagytam az előbb, bocsi.
-
Az egész select-et tedd be az NVL első paraméterbe. (zárójelben)
NVL(
(select count(*) from...)
, 0)Ez akkor jó, ha lehet olyan eset, hogy ha egy sorral sem tér vissza a lekérdezés.
Nekem így nem akar működni.
de ha a COUNT után nem csillagot, hanem a táblát írom, így elhagyhatom a Group-ot a végéről, és így működik is rendesen Köszönöm szépen a segítséget -
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 -
Louro
ő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!
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.
-
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.
É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.
-
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
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.
-
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_datumszerintem 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
-
Szmeby
tag
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.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.
-
Apollo17hu
őstag
-
tm5
tag
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!
-
bambano
titán
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!
-
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!
-
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.
-
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.
-
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.
-
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.
-
É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.
Köszönöm!
Ismeri a 2.5 is, az analitikus függvények viszont ha jól emlékszem csak 3 -tól vannak, de CTE -vel más módon szerintem megoldom majd. Csak olyan ritkán kell DB -t piszkálnom, hogy már elfelejtem melyik mit is tud
-
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. -
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
-
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
-
-
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.
-
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 -
Ó, é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. -
Ó, é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.Nézd, ha valaki kurvának áll....tudod.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
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.
Ó, é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. -
Á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.
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.
-
Á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.
É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.)
-
Nem egy nagy céget tudok, ahol több, mint 10 éves rendszerekkel dolgoznak. SQL Server 2008, de az Internet Explorer 6 is egy vicc kategória már. De hát "erre fejlesztettek." Ez a mondás.
Á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.
-
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.
-
Látom te is hasonló módon tördeled a kódjaid....annyira hiányzik az SQL nyelvre egy clean code iránymutatás
Kollégák, amikor egy sorba behánynak mindent, attól a falra tudnék mászni.
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.
-
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.
Látom te is hasonló módon tördeled a kódjaid....annyira hiányzik az SQL nyelvre egy clean code iránymutatás
Kollégák, amikor egy sorba behánynak mindent, attól a falra tudnék mászni.
-
Ü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? -
Ü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? -
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. -
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.
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. -
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 -
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. -
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. -
OldBoyDev
csendes tag
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
-
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.
-
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...
-
Köszönöm. Nekem is ez a legizgalmasabb a jelenlegi munkámban, bár többnyire SQL-ben oldom meg. Persze a vizualizáció Excel-ben történik - sajnos.
Esetleg tudsz mondani egy példát, hogy mi az, amit SQL-ben nem lehet vagy rosszabbul, mint Python-ban? De érzem, hogy pont a vizualizáció lesz a kulcs
-
"mert össze akarok rakni egy dashboardot arról, hogy 1. megy a rendszer 2. jók az adatok.": én nem találnám fel n+1-edjére a melegvizet, ilyen cucc van kilószám a neten.
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
- Milyen routert?
- Fejhallgató erősítő és DAC topik
- exHWSW - Értünk mindenhez IS
- Visszatérés az aranykorba: Heroes of Might and Magic: Olden Era Early Access
- Négy másodperc alatt betölt a Forza Horizon 6 a Microsoft csodatechnológiájával
- Milyen TV-t vegyek?
- Külföldi prepaid SIM-ek itthon
- Milyen ÚJ notebookot vegyek?
- Digitális Állampolgárság Program DÁP
- Kormányok / autós szimulátorok topikja
- További aktív témák...
- BESZÁMÍTÁS! Asus X570 R7 5700 16GB DDR4 1TB SSD RTX 3060Ti 8GB be quiet! Pure Base 500 Chieftec 700W
- Új 27% - ASUS TUF Gaming TF120 ARGB 3-pack FEKETE (90DA0030-B09030)
- HP ProBook 445 G8 14" Ryzen 3 5400U, 8GB RAM, 256GB SSD, jó akku, számla, 6 hó gar
- Beszámítás! Apple Mac Mini 2023 M2 8GB 256GB számítógép garanciával, hibátlan működéssel
- HP EliteOne 800 G6 All-in-One i5-10500 16GB 512GB 24" Érintőkijelző!! 1 év garancia
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest