Új hozzászólás Aktív témák
-
Jim Tonic
nagyúr
válasz bambano #3036 üzenetére
Meg tudtam csinálni, kisebb mértékben kellett csak módosítani a DDL-t, hogy hiba nélkül lefusson. Adatokat majd áthalászom.
Azt meg majd meglátom, hogy nekiállok el lecserélni a char(1)-t booleanre. Az már a programot és érinti.Alcohol & calculus don't mix. Never drink & derive.
-
Novics
senior tag
válasz bambano #3087 üzenetére
3 lekérdezés? Egyikben a szemad-ban a névhez tartozó jogvisz_kezd, a másikban a kmh-ben a dolg-hoz tartozó min(kezdet) where beszamithato. Mi a harmadik?
Találtam egy jónak tűnő leírást az unionról, de még nem volt időm átrágni magamat rajta. Arra gondoltam, hogy berakom egy táblakészítő lekérdezésbe, aztán utána arra is ráeresztek egy min()-t. Ez az igazán kőbalta, vagy inkább sima husáng megoldás!A fontolva haladó. - 30 felett minden nap ajándék.
-
-
bpx
őstag
válasz bambano #3100 üzenetére
Azért, mert akkor született a döntés a napok kihagyásáról, és az Oracle meg fogta magát, és ezt vette alapul. Kipróbáltam, a területi beállításoknak erre nincs hatása, tehát én hiába állítom pl. UK-ra, attól még nem fogja az 1752-t 355 naposnak számolni, hanem ugyanúgy 1582-t mondja rövidebbnek.
-
PumpkinSeed
addikt
válasz bambano #3475 üzenetére
Mit értesz az alatt, hogy soha nem szokott jól sikerülni? Csak mert a Cassandra konkrétan erre lett tervezve. Szóval szerinted NoSQL adatbázis ne is jöjjön szóba?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
PumpkinSeed
addikt
válasz bambano #3477 üzenetére
Hm, hát jó. Igazából a kérdés az lett volna nagyjából kicsit átfogalmazva, hogy mi a javaslatotok elosztott adatbázisokra? De részben kaptam is rá választ.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
sztanozs
veterán
válasz bambano #3490 üzenetére
nem tudom, hoogy mostanában hogy optimalizálnak az SQL szerverek, de anno a
not in
az egyik legdrágább feltétel volt.JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
nagyúr
válasz bambano #3590 üzenetére
sql developer van ezen a vm-en, itt azt mondja tools/preferences/enviromentben, hogy encoding utf8.
database/nls mindenhol hungarian.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
nagyúr
válasz bambano #3595 üzenetére
mármint az oracle sql developerben? nem, nincs. legalábbis én nem találtam. encodingnál van utf8, meg utf-8, de nem láttam különbséget közöttük használat során.
[ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
tm5
tag
válasz bambano #3645 üzenetére
Ezt sqlfiddleben raktam össze:
/*schema setup:*/
create table t1(c1 integer);
insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);
insert into t1 values (4);
insert into t1 values (6);
insert into t1 values (7);
insert into t1 values (10);
insert into t1 values (11);
/*a query:*/
select * from (
select c1,
CASE
WHEN plus1 != kovetkezo THEN 'vegelem'
WHEN minus1 != elozo THEN 'kezdoelem'
WHEN elozo IS NULL THEN 'kezdoelem'
WHEN kovetkezo IS NULL THEN 'vegelem'
ELSE 'kozbulso'
END tipus
from
(select c1, c1-1 minus1, c1+1 plus1, lag(c1) over () elozo, lead(c1) over () kovetkezo from t1) t) tt
where tipus != 'kozbulso';ezután már csak egy pivot kéne, de arra már nem volt energiám
-
nyunyu
félisten
válasz bambano #3645 üzenetére
Ilyesmi feladatba már sikerült belefutnom melóhelyen.
Ottani kódom erősen leegyszerűsítve.DB adminjaink persze nem szoktak szeretni érte, amikor több millió soros táblákból kell kibogarásznom pár tízezer hasznos rekordot, majd azokat intervallumokba rendezni...
Query plant kielemezve mindenféle Cartesian join kerülendő szakszavakkal dobálózva próbálják levenni a rontást a DB performanciáról.Hello IT! Have you tried turning it off and on again?
-
kw3v865
senior tag
válasz bambano #3666 üzenetére
Köszi a tippet, utánanézek. Eddig nem kellett foglalkoznom különösebben a performanciával, de most fontossá vált.
Még arra gondoltam, hogy az elején a CASE WHEN ST_Intersects(p.geom,pr.geom) then 'TRUE' ELSE 'FALSE' vajon elhagyható-e valahogy? Mert ugye most az ST_Intersects függvényt kétszer hívja meg, hiszen a JOIN is ezen alapul. Nekem az a cél, hogy ne csak a TRUE, hanem a FALSE rekordokat is lekérdezzem. Jobb módszert egyelőre nem találtam.
-
kw3v865
senior tag
válasz bambano #3687 üzenetére
Végül is a megoldás az lett, hogy egy másik hisztogram-készítő függvényt találtam, ami már tökéletesen megfelel az elvárásaimnak: http://blog.faraday.io/how-to-do-histograms-in-postgresql/
-
kw3v865
senior tag
válasz bambano #3748 üzenetére
@bambano
A célirányos indexek mit jelentenek tulajdonképpen? Hol tudok erről olvasni angolul? Most térbeli indexeket használok, ez sokat segít, ezek nélkül sokkal lassabb lenne.
@VirsLee
Autóban van a rendszer, valós időben kell működnie, max. 100 km/h-ig, de többnyire 80 alatt (teljesen offline, minden localhoston). Kapja a koordinátákat a nagy pontosságú GPS-től, és elsősorban térbeli lekérdezéseket kell futtatni. Jelenleg szimulálva megy a dolog, egy korábban rögzített track alapján, most éppen 25 ms-st állítottam be frissítési gyakoriságnak. ilyen gyakorisággal hívja meg a függvényeket. Többnyire PostGIS-es függvényeket használok, de ezeket kombinálom is általában, pl. a legközelebb lévő objektumok távolságát kell kiszámolni, vagy jeleznie kell, amikor az autó egy poligon területére megy rá, ilyenek. Alapvetően egyelőre meg vagyok elégedve a teljesítménnyel, de amikor bővülni fognak a funkciók (nem csak SQL, egyebek is), akkor azért már számíthat, hogy mennyi erőforrást igényel, sajnos a hardver teljesítménye korlátozott (bár aránylag jónak mondható). -
K1nG HuNp
őstag
válasz bambano #3779 üzenetére
jó mondjuk ez egy érettségi feladat, ha katyvasz de működik is max pont
ettől függetlenül akkor hozzászokom a másikhoz, én sem szeretnék rossz berögződéseket, kösz az infót!
(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()
-
-
Johnny_vT
senior tag
válasz bambano #3817 üzenetére
Nem vitatkozni akarok, hiszen az ügyben nincs tapasztalatom. Viszont logikailag nem látom miért lenne a hirdetett járművek adatainak begyűjtése jogsértő, hiszen azok teljesen nyilvánosan publikált adatok, amiket én is, te is bármikor elérhetünk a weboldalon. A különbség, hogy nem a mobile lassú kezelőfelületét kell nyomkodni hozzá, hanem egy Excel táblát / adatbázist pörgetni.
Analógia (szerintem): mintha egy koncerten egyesével kéne mindenkitől megkérdezned, hogy milyen színű pólót hord, de ehelyett te a lelátóról összeszámolod magadnak.
A személyes adatok (mint név, telefonszám) ehhez szükségtelenek is lennének. Bár az tény, hogy valószínűleg csak egy extra lekérdezésen múlna azok kigyűjtése is, azaz a lehetőség adott rá (de ezek is nyilvánosan az oldal minden user-ének).
- És te hogy neveznél egy baromi gyors, apró, kék izét...?
-
Tanisz
senior tag
válasz bambano #3820 üzenetére
Azért ez nem ilyen egyértelmű, de jó amit írtál, teljesen rendben van, abszolút jogos. Egyetértek.
Viszont az árnyaltság miatt: hiszen, ha ő azért gyűjti az adatokat programmal is akár a weboldalról, hogy a saját autóvásárlásához segítse magát, és szűrt, szempontok alapján adatok érdeklik csak amiket később kielemez, az kb ugyanaz, mintha excelbe kézzel bepötyögné és onnan alkotna halmazokat és eredményeket saját magának.
Ez nekem nem volt egyértelmű Johnny_vT kérdéséből, bár lehet benéztem
Viszont amit Te is írtál, hogy azért gyűjtené az adatokat, hogy egy 3. személynek vagy személyeknek nyújtson információkat belőle akár haszonszerzés miatt is, az valóban adatlopás és személyes adatokhoz fűződő adatvédelmi jog megsértése.
http://projekt.azigazikincs.hu/ ''Homo loquax nonnumquam sapiens''; "Nam et si ambulavero in valle umbrae mortis, non timebo mala, quoniam tu mecum es. Virga tua et baculus tuus, ipsa me consolata sunt. "
-
sztanozs
veterán
válasz bambano #4139 üzenetére
hozzátenném, hogy nagyobb táblákban a
not in
sql formula kerülendő (mert nem hasít, hanem és végig iterál a táblán annyiszor amennyi elemet ellenőrizni kell, és ezen még az indexek jelenléte sem segít)[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
-
sztanozs
veterán
válasz bambano #4145 üzenetére
ehh, ott maradt az id az elején, megzavart az anonimizálva
szóvalexplain select * from customer c where not exists (select customer_id from <anonimizálva> a where c.id = a.customer_id );
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz bambano #4148 üzenetére
ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz
Elméletileg pont fordítva. A NOT IN-hez kell iterálni, az NOT EXISTS anti-joinra konvertálható (csak ebben a formában szebb).Analyse jól írja, mert tényleg pont fordítva van, mert az exists és a left join + null is anti-joinra van optimalizálva, a not in pedig hashed subplan (mert az IN értéket és null-t is visszaadhat, ezért kétszer fut az iteráció - ki elemszámnál ez nem probléma, de nagy elemszámnál már lesz különbség, ráadásul a subplan miatt cache problémák lehetnek).
EXPLAIN ANALYZE
It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows.[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Apollo17hu
őstag
válasz bambano #4171 üzenetére
Volt korábban ugyanezzel a kóddal memóriaprobléma, de az egyértelmű volt, mert 15 perc után hibaüzenettel leállt. Szerencsére rájöttünk az okára (kb. az volt, hogy a 20 allekérdezés miatt 3^20 szorzót kapott a memóriában elfoglalt mérete, de extra kötésekkel, ezt áthidaltuk).
Temp tábla sajnos nem játszik. Maga a keretrendszer úgy néz ki, hogy különálló sql-eket tárolunk, amelyeket egy alkalmazás minden nap meghív, lefuttat, az eredményt pedig Excelbe másolja. Nincs lehetőség egymásra épülő kódrészletek megadására.
@bpx: Jogos, fejből írtam, de élesben jó helyre raktam a hintet. Ezt a materialize-t még kipróbálom, mert tényleg annyira lenne csak szükség, hogy külön-külön meglegyen az allekérdezések eredménye, utána már 2 másodperc alatt kiszámolja.
-
Jim74
nagyúr
válasz bambano #4176 üzenetére
Az adatbázisban int-ek az adatok, de ahol 0 a beérkező hívás, ott nincs értelme megválaszolási arányt számolni, ezért szeretnék az arányszám helyett 'N/A' string-et kiíratni.
Közben sikerült megoldanom
CASE WHEN CAST(app.CallsOffered as INT) = 0 THEN 'N/A'
ELSE CAST(app.CallsAnswered*1.0/CallsOffered as VARCHAR) end as AnswerRateKöszönöm a segítséget
-
Apollo17hu
őstag
válasz bambano #4179 üzenetére
Nem, vagyis én próbálok mindig a legjobb tudásom szerint kódolni, de mezei kontrollerként nem értek az optimalizáláshoz. Egyébként azt a 20 darab allekérdezést össze tudnám gyúrni 5-6-ba, de akkor egy potenciális jövőbeli hibakeresés sokkal tovább tartana (nekem is, de méginkább olyasvalakinek, aki nem ismeri a kódot). Az én szemszögemből az lenne a legegyszerűbb, ha egy táblából tudnék leszedni mindent, de a mostani mókolás is azért kellett, mert nincs IT erőforrás a fejlesztésekre.
Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód.
Új hozzászólás Aktív témák
- Asus K95VJ, 18,4" FHD, I7-3630QM 8x3,40 GHz, 16GB DDR3, 250GB SSD+1TB HDD, 1GB VGA ,WIN 10, Számla,
- Asus R751L, 17,3" FHD, I7-4510U, 8GB DDR3, 1TB HDD, 2GB VGA ,WIN 10, Számla, garancia
- IdeaPad 1 15ALC7 15.6" FHD Ryzen 5 5500U 16GB 512GB NVMe SSD (PCIe 4.0) gar
- Asus N73S, 17,3" FHD, I7-2670QM 8x3,10 GHz, 16GB DDR3, 250GB SSD,500GB HDD, 2GB VGA ,WIN 10, Számla,
- Asus K75VJ, 17,3" HD+, I7-3630QM 8X3,40 GHz, 16GB DDR3, 250GB SSD, 2GB VGA ,WIN 10, Számla, garancia
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen