Hirdetés
- One otthoni szolgáltatások (TV, internet, telefon)
- Synology NAS
- Windows XP
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Milyen routert?
- Egy vagyont költ humanoid robotokra az egyik kínai EV-gyártó
- Milyen NAS-t vegyek?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- A napot és a szelet is akarják az adatközpontok
- Videó stream letöltése
Új hozzászólás Aktív témák
-
Taci
addikt
Az a nagyon-nagyon fura, hogy a mysql-bin fájlok tartalmazzák jó pár .php fájlok tartalmát.
Semmi közül az adatbázishoz, erre ott virít a tartalmuk a binary log fájlokban...Most fogtam egy 2,8 MB-os mysql-bin fájlt, megnyitottam Notepad++-szal, és csak felületesen, de kitöröltem belőle a php szkriptjeim tartalmát.
A végeredmény fájl mérete 13 kB. (Ezt gondolnám reális méretnek egy inkrementális mentésnél ennyi új adatra.)Én ezt nem értem. Mi történik itt?
-
nyugis21
kezdő
Köszönöm!
Sajnos megfertőztek coviddal, eltart egy ideig, amíg túlleszek rajta.:-(
Ráadásul a webbel is bajok vannak, levelező weboldalnak lejárt valami tanúsítványa, napok óta nem kapok leveleket, nagy nehezen be tudok lépni, küldeni tudok, de válaszok "kézbesíthetetlenek"?
yt-ről se tudom a videókat letölteni, még azokat se, amik korábban letölthetőek voltak, a letöltök nem találják a fájlt, vagy időtúllépés.:-(
-
bambano
titán
"Kérdés, hogy a bíróság elfogadja-e ezt hitelesnek.": nem és nem.
tehát nem kérdés, nem fogadja el.
az elektronikus személyire pakolható elektronikus aláírás kettő évig érvényes, ezért az aláírás csak akkor érvényes, ha a dokumentumon olyan, magas biztonságú időbélyeg is van, amelyik az aláírás érvényességi idejébe beleesik. -
Louro
őstag
Egy dolog kimaradt, bár ez inkább megint oldschool és úgy tudom Oracle-nyavalya, de nagyon sokan használják még, mert a veterán kollégák "így mutatták neki".
select tabla1.*
from tabla1,tabla2
where tabla1.id = tabla2.id (+)
and tabla2.id is null;Én is jobban szeretem a könnyebb olvashatóságot, azaz a
select tabla1.*
from tabla1
left join tabla2
on tabla1.id = tabla2.id
where tabla2.id is null;Amikor inner join, sokan elhagyják az inner szót. Vagy az outer is sokszor el van hagyva. Nem left outer join, hanem csak left join. Bevallom nem is tudom mit lehetne az outer helyett írni. left inner join?
nyunyu: sql server 2008-nál még biztos kötelező volt aliast használni subquery esetén is. Lehet az újabbaknál már nem, de annál biztos kellett.
-
Micsurin
nagyúr
Köszönöm! Az a baj most nem gyakorlati dologról beszélünk hanem egy zh-ról. Ott meg ha a subquerry erőltetése a feladat x-y formátumban akkor arra fog járni a pont bármennyire is életszerűtlen a feladat szaga. Emiatt nem tudom pontosabban megfogalmazni a most bugyutának tűnő kérdésem! De így, hogy csak a forma tér el valamivel tisztább köszönöm!
nyunyu Életemben először látom de magát az oracle sql-t is eddig csak mysql-lel kellett dolgozzunk, felcsesz ez a szintaktika. LIMIT helyett is mire megtaláltam ezt a ROWNUM cuccot és rájöttem, hogy subquerry megy ebbe is vagy van FETCH azt hittem megőszülök.
Majdnem jó tipped volt ez most nem BME hanem OE.Neked is köszönöm!
Ergo maradhatok a JOIN-oknál és csak arra kell figyeljek milyen formában ad vissza a subq adatot és azt miképp illesztem JOIN-al. Miért nem lehetett ezt így leírni a jegyzet vagy a ppt-ben?
Igen már az EXISTS sem "tiltott" dolog, sőt..., kicsit fura az egész... de még ez az értelmes része a tranzakciók meg ez a terminálos dolog végképp elveszi a türelmem sose akartam bigdatara menni de miután tudom, hogy oracle-öznek még annyira se mint eddig.
Köszönöm a válaszokat!
martonx Legközelebb oda fogom feldobni akkor, nem tudom jobban leírni mert egy minden gyakorlatiasságot nélkülöző PPT példa alapján kell rájönnöm, hogy mit is akarok kérdezni.
-
nyunyu
félisten
Meg az exists egy olyan okossag, ami egesz jo hatekonysagot mutat, annak a probalgatasat is ajanlom.
Nem volt mindig így.
Tizenéve még kifejezetten kerülendő antipatternként tanították az EXISTS/NOT EXISTS párost, mivel régi DBken nagyon rosszul futottak.
Modern DBk optimalizálói viszont végrehajtás előtt át szokták alakítani LEFT JOINra, és úgy futtatják.
Szóval a
select *
from tabla1
where not exists (select id from tabla2);helyett már
select tabla1.*
from tabla1
left join tabla2
on tabla1.id = tabla2.id
where tabla2.id is null;végrehajtási tervét fogod látni, és futtatási sebességben sem lesz köztük különbség.
Régebbi/kevésbé fejlett optimalizálóval rendelkező DB motorokon viszont a második kód sokkal gyorsabban fut, mint az első.
-
-
#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. -
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 -
#4504
Apollo17hu
őstag
Szmeby
#4503
Apollo17hu
őstag
Bocs, hogy beleszólok, de Lourohoz hasonló munkakörben dolgoztam, és csak megerősíteni tudom:
- High-level menedzsernek nem fogod tudni elmagyarázni. Nem érdeklik a részletek ilyen mélységben, és nem is akarja megérteni, mert nincs ideje rá. A közvetlen vezetődnek mondhatod, de ő nagyon jól tudja, hogy a nála nagyobb emberek az ilyesmit egyszerűen lesöprik az asztalról. Csak az eredmény számít.
- A másik dolog pedig az, hogy felsőbb szinten a vezetők hajlamosak (sőt, néha kötelező az előmenetel miatt) rotálni szervezeten belül. Tehát, ha 3-5 évig működik a toldozás-foldozás, akkor nyert ügye van, mert úgyis dobbant máshova....és ennek analógiájára: az a fejlesztő balek, aki próbál prudensen, hosszú távban gondolkodva végezni a dolgát. Ahhoz képest mindenképp, aki összehányja a munkát, de feleannyi idő alatt eredményt mutat fel, és 2-3 évente munkahelyet vált (aminek következményeként nem kell saját maga után takarítani).
-
Louro
őstag
[Személyes vélemény on]
Ez témába nem vág, csak a kérdésre válasz
:
A feladatok el vannak látva. Még plusz is. Többieknek segítek. Megosztom az infót és a társosztályoknak is segítek, amitől az osztály reputációja is nő. A fennmaradó időben próbálom javítani a rendszerünket, spórolni erőforrásokat. Amikor a jelenlegi helyemre kerültem, annyira nem volt kapacitás, hogy folyamatosan jobokkal dolgozott az adatbázisszerver. Volt, ami több, mint 3 órát futott. Kis átírással 10 perc alatt lefutott. (Több nagy tábla összekötve egy lekérdezésben, indexek nélkül. Ezeket szedtem szét több kisebb lépésre.)A fejeseknek az a fontos, hogy az ő felettük állók igényei ki legyenek szolgálva és persze mindenki fel akar valamit mutatni, de azzal nem foglalkozik, hogy a meglévő rendszerrel faragjon, mert túl kocka terület. Sajnos ilyennek miatt olyanok a nagyobb cégek rendszerei, amilyenek. Szívás minden fejlesztés.
[Személyes vélemény off]
-
Louro
őstag
Nem saját termékről van szó, hanem egy dobozos termékről, ami kötöttségekkel jár. Ezért az SQL server is. Rendelkezésre áll a SAS is, de arra átállni (backup esetén) meg idő lenne, amire persze nem szánnak időt. Rengeteg idő lenne a meglévő jobokat átírni
Én sok kis lépéssel próbálok javítani. Igazából szorgalmiként, mert mellette ott vannak a feladataim is :/
-
MrSealRD
veterán
Így önmagában semmi... Az 1 képernyős karbantartást meg lehet oldani több tábla esetén is. Én csak megosztottam az érvelést amit kaptam.
nyunyu : Ez mondjuk nem adattárház lesz. Viszont mivel tervezési fázisban vagyunk ezért én próbálok minden esetleges vonatkozást megvizsgálni. Most a Hibernate is elgondolkodtatott... Ott is vannak kérdőjelek az egyesített tábla miatt.
-
#4443
DrojDtroll
veterán
Szmeby
#4439
DrojDtroll
veterán
-- Table: public."neighborStationLine"-- DROP TABLE public."neighborStationLine";CREATE TABLE public."neighborStationLine"("lineId" integer NOT NULL,"stationId" integer NOT NULL,"nextStationId" integer NOT NULL,"travelTime" time without time zone NOT NULL,index integer,CONSTRAINT "neighborStationLine_pkey" PRIMARY KEY ("lineId", "stationId", "nextStationId"),CONSTRAINT lineneighborfk FOREIGN KEY ("lineId")REFERENCES public.line (id) MATCH FULLON UPDATE NO ACTIONON DELETE NO ACTION,CONSTRAINT stationfk3 FOREIGN KEY ("stationId")REFERENCES public.station (id) MATCH FULLON UPDATE NO ACTIONON DELETE NO ACTION,CONSTRAINT stationfk4 FOREIGN KEY ("nextStationId")REFERENCES public.station (id) MATCH FULLON UPDATE NO ACTIONON DELETE NO ACTION)WITH (OIDS = FALSE)TABLESPACE pg_default;ALTER TABLE public."neighborStationLine"OWNER to postgres;
![;]](http://cdn.rios.hu/dl/s/v1.gif)
amikor a tanárral megbeszéljük akkor tök érthető, de majd gyakorolgatok hátha jobban bele jövök 
Új hozzászólás Aktív témák
- Dell XPS 9310 (i7-1185G7/16 GB RAM/512 GB SSD)
- Intel NUC 8i7BEK Mini Desktop
- Új 2K Gamer PC Ryzen 5 7600/RTX 4060 Ti 8Gb/16Gb DDR5/500Gb NVME SSD/750W 2-3Év gari (27% ÁFÁ-s)
- Új 2K Gamer PC Ryzen 5 7600/RTX 4060 8Gb/16Gb DDR5/500Gb NVME SSD/750W 2-3Év gari (27% ÁFÁ-s)
- Xiaomi Redmi Note 12 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest