- Ubisoft Forward 2024 - Az összes bejelentés egy helyen
- UbiForward24 - Jön az Anno 117: Pax Romana
- UbiForward24 - Hosszabb játékmenet videón az Assassin's Creed Shadows
- UbiForward24 - Sztori kiegészítőt kap az Avatar: Frontiers of Pandora
- UbiForward24 - Prince of Persia: The Sands of Time Remake csak 2026-ban
- Ubisoft Forward 2024 - Az összes bejelentés egy helyen
- Xbox Series X|S
- Call of Duty: Black Ops 6
- PlayStation 5
- UbiForward24 - Hosszabb játékmenet videón az Assassin's Creed Shadows
- Marvel Snap
- EAFC 24
- Diablo IV
- UbiForward24 - Hosszabb bemutatón a Star Wars: Outlaws
- UbiForward24 - Prince of Persia: The Sands of Time Remake csak 2026-ban
Új hozzászólás Aktív témák
-
Louro
őstag
válasz bambano #4197 üzenetére
A HAVING-et általában subselect-tel oldják meg az emberek. Az első kettő az nagyon alap. A 3. feladatnál csak arra voltam kíváncsi, hogy kétségbeesik vagy nem. HAVING simán helyettesíthető. Csak azzal elengánsabb.
Már a 2. olyan kolléga van mellettem, akik több év elemzés után nálunk találkozott a ROW_NUMBER()-rel. Én meg amikor autodidakta módon tanultam, annyira alapnak véltem.
De az se mindegy, hogy mennyi tábla van összekötve. Előző osztályvezetőnk olyan kódot írt, amiben legalább 15 tábla volt LEFT JOIN-nal összekötve. (MSSQL.) Tetű lassú volt. 4-4,5 órát futott. Azzal, hogy szétszedtem 4 részre, 20-30 perc alatt megvolt az eredmény. Semmi mást nem néztem, de van egy olyan érzésem, hogy lehetne performanciát javítani.
Itt arra akarok utalni, hogy nem elég, hogy valaki ismeri a főbb parancsokat, igényesnek is kell lenni és gondolni kell arra, hogy limitált az erőforrás. (A rengeteg temptábláról nem is beszélve. Egy hónapig takarítottam, a GDPR bevezetése előtt.)
Speciális dologkra interjún nem is kérdeztem, mert úgyis ott a gugli. Én is használom, ha elakadok vagy keresek gyorsabb, jobb megoldásokat. Hülyeségnek tartottam mindig, ha interjún valaki nagyon mély ismeretre kérdezz. A jelentkező is lehet tudna olyat kérdezni, amit meg az interjúztató nem tudna :/
[ Szerkesztve ]
Mess with the best / Die like the rest
-
-
kezdosql
tag
válasz bambano #4203 üzenetére
Igen, felreertetted teljesen.
A Clipper az egy jo megoldas volt a problemara, hogy laikusokat tavol kell tartani az adatoktol.
dBase adatbazisokat kezelt (szerintem inkabb tablakat, mert sql akkor meg nem volt) es dBase programokat hasznalt, kesobbi verzioja mar mas programokbol is elfogadott bizonyos reszeket.A nagy elonye az volt, hogy amikor a forraskodok keszen voltak, a program minden resze mukodott, akkor leforditva volt egy exe program azt kellett elinditani, es a buta user csak azt tehette, amit a menuk reven elerhetett. A buta user boldog volt, mert latta az adatokat menuben, listaban, tablazatban, ahogy menuk kozott valtott, es biztonsagos volt, nem volt lehetoseg adatokba belebarmolni.
Az sql megjelenesevel kellett egy php, vagy c vagy mas program, amivel lehetett kezelni es megjeleniteni az adatokat, majd jott a bongeszos megoldas, amihez html, css es javascript is kellett, es persze servert kell telepiteni, frissiteni, upgradelni, stb.
A buta userek pedig ragaszkodnak a tablazatkezelos megjeleniteshez, mert ok azt ertik, ezert el az excel evtizedekkel az elavulasa ota is.
A kerdesem az volt, hogy van-e olyan megoldas, hogy amikor kesz egy sql adatbazis lekerdezeset es megjeleniteset megoldo forraskod, azt leforditva van egy exe fajl es nem kell servert telepiteni, stb.
Egy jo pelda a hataridonaplok esete. Rengeteg egyszeru es bonyolult megoldas letezik ra, valoszinuleg a tobbseget c-ben vagy hasonlo nyelven irtak, de egyikkel se lehet teljes koru keresest vegezni, mert mindegyik csak a dBase-n alapulo szemlelettel mukodik, egy szempont szerint lehet keresni, komplex modon nem, amit az sql lehetove tesz.
Most szenvedunk rendesen, mert kenyszerusegbol egy excel tablaban vannak adatok, amit jellemzoen negyfele adat - datum, meret, szin, hely - tetszoleges kombinaciojaval kell keresni, amihez az excel tablat mindig at kell rendezni, emiatt allandoak user error-ok.:-(
Ha lenne egy egyszeru alkalmazas, ami csak annyit tud, hogy negy adat tetszoleges kombinaciojara lehet vele keresni, sot szurni a megjelenitendo adatokat, meglenne a boldogsag.
-
nagyúr
válasz bambano #4233 üzenetére
azt írja, hogy az avg() okoz integer overflow-t. ha a datetimeja current_timestamp alapú lenne (2019.08.08 ...), akkor már a datediff()nél túlfolyna az integer, szóval feltételezem, hogy az 1900.01.01.-re van rátéve az idő, és csak nagyon sok adatsor van.
[ 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.
-
Male
nagyúr
válasz bambano #4360 üzenetére
Ha a neten van, és nem tudja az elérhetőséget meg a user/passt, mert hardkódolva van a programban? Legalábbis feltételezem, hogy a program felhasználói felülete nem olyan, hogy a pincérek gépelgethetik be az SQL utasításokat, és egy sima config szövegfile sem tuti hogy van ezekről amiből kinézhetné.
...de már lényegtelen, mert kiderült, a gépen van az SQL szerver nála. -
kw3v865
senior tag
válasz bambano #4392 üzenetére
Köszönöm mindkettőtöknek a válaszokat! Több érdekes dolgot írtatok, az API-s megoldást elvetném, mert nem sok fogalmam van róla. Kicsit bővebben is kifejtem, mi lenne a cél: adott néhány kliens gép (jelenleg 3-4 db), ezek folyamatosan gyűjtik az adatokat és eltárolják egy táblában (localhoston). A cél az lenne, hogy szinkronizálni lehessen ezeket, azaz minden egyes gépen futó szoftver elérhesse (read only) a többi által rögzített táblák tartalmát. A szinkronizációnak nem szükséges valós időben megtörténnie, hiszen az is előfordulhat, hogy éppen nincs internet elérésük (földrajzilag mozgásban vannak a gépek). A gyakorlatban ez úgy nézne ki, hogy ha végeztek egy adott feladattal, akkor történne meg a szinkronizálás (néhány óránként).
Így, hogy alaposabban is tágondoltam, tulajdonképpen nem is szükséges ehhez, hogy PostgreSQL fusson a szerveren, ha az rsync-es megoldást használnám. Persze lenne egy szerver, melyre szinkronizálva lennének a táblák, és a kliensek innen szednék le a frissített txt-ket is, és ezután lennének frissítve a táblák a klieneseken. Vajon ez így működhet?
-
Laca0
addikt
válasz bambano #4435 üzenetére
PgadminIII-ban szerettem volna ezt a műveletet elvégezni úgy, hogy már csatlakozva vagyok a szerverhez. A dblink-nek csak adatbázis paramétert adtam meg, mert ugyanaz a connection. De igazából fel sem ismerte a D link függvényt/eljárást. Szerintem ez alapból nem része a rendszernek.
Xiaomi 11 Lite 5G NE Dual 8/128 | Redmi Note 8 4/64 | MikroTik hAP AC2 | Sony KD-55XH8096 | LG 47LM620S | Denon AVR-1612 | Eltax Experience 5.0 | Egreat R6S
-
Apollo17hu
őstag
válasz bambano #4461 üzenetére
Fognám a calendar táblát, raknék rá egy "nagyobb, mint a bemenő dátum" ÉS "legyen munkanap" szűrést, majd a kapott halmazon valamilyen rank() függvénnyel (van ilyen postgresql-ben?) egy sorszám mezőt generálnék, ami dátum szerint növekvő sorrendben osztaná ki a sorszámot. Ahol a sorszám n, az a keresett dátum.
Ehhez mondjuk az is kell, hogy az ünnepnapokból és a munkanap áthelyezésekből rendelkezésre álljon egy munkanap flag ['I', 'N'] is. Ha ilyen nincs, azt mondjuk egy CASE WHEN-nel külön le kell még kezelni.
-
nyunyu
félisten
válasz bambano #4461 üzenetére
Oracle:
with extra_nap as (
select '20200410' datum, '7' nap from dual
union
select '20200413' datum, '7' nap from dual
union
select '20200501' datum, '7' nap from dual),
szamok as (
select level l
from dual
connect by level <= 1000),
datumok as
(select to_char(sysdate+l,'yyyymmdd') datum,
case when nvl(e.nap, to_char(sysdate+l,'d')) in ('1','2','3','4','5') --hétfő..péntek
then 'Y'
else 'N'
end munkanap
from szamok l
left join extra_nap e
on e.datum=to_char(sysdate+l,'yyyymmdd'))
select datum, row_number() over (order by datum) rn
from datumok
where munkanap='Y';Extra_nap "táblába" felvettem a nagypénteket, húsvéthétfőt, május elsejét vasárnapi munkarenddel.
Aztán legenerálom a következő 1000 nap dátumát, és melléteszek egy munkanap flaget, ami az extra_napban beállítottból vagy a hanyadik nap a héten értéktől függ.
Végül leválogatom a munkanapokat és melléteszek egy sorszámot, hogy ő hanyadik.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
bambano
titán
válasz bambano #4461 üzenetére
én erre jutottam:
1. generálom a következő napok dátumait
2. ebből kidobom, ami szerepel a calendar táblában
3. kilistázom a maradékból a munkanapokat, sorbarendezve
4. a listából az n. elemet lekérdezemamiben nagyon más: van generátor függvény, ami többek között dátum típusra is működik, és az ünnepeket egy not in subselect halmazzal szedem ki.
kb. így néz ki postgresql-ben:
select l.nap,date_part('dow',l.nap),
to_char(l.nap,'YYYYMMDD') as kompaktdatum from
(select date_trunc('day',generate_series(now()+'1 day'::interval,
now()+'30 days'::interval,'1 day'::interval)) as nap ) l
where l.nap not in (select distinct date from calendar where date>now()
and date<now()+'30 days'::interval)
and date_part('dow',l.nap) in (1,2,3,4,5) order by l.nap limit 1 offset 5;
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
nyunyu
félisten
válasz bambano #4472 üzenetére
Nem elég azt nézni, hogy benne van-e a dátum a calendarban, hanem azt is kéne nézni, hogy az extra nap milyen napnak számít, különben elveszted a soknapos ünnepek körül elcserélt szombati munkanapokat.
Ezért volt plusz egy oszlop az ügyfeleinknél használt naptár táblákban, ahova a munkanapcserés szombatokat is fel kellett vennem péntek értékkel, előtte pénteket meg csütörtökkel, amikor egy évre előre felvettem az ünnepnapokat.NOT IN vs LEFT JOIN?
Annak idején úgy tanultuk, hogy jobb az anti join teljesítménye, de nem tudom ez a mai DB kezelőknél mennyire áll még fenn.
Oracle optimalizálója alapból anti joinná alakítja a not in-t, hacsak nem tiltod meg neki, így ott már nincs különbség teljesítményben.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Jim Tonic
nagyúr
válasz bambano #4529 üzenetére
Köszi mindenkinek, sikerült megoldanom. Még egy gyors kérdés:
Ha kombinálnom kell min és max értékeket (max(valid_from) és min(valid_to)) akkor az csak dupla select-tel megy, ugye? Mármint azzal megoldom, csak nem tudom, van-e egyszerűbb megoldás.[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
Jim Tonic
nagyúr
válasz bambano #4544 üzenetére
Ki kell szednem a valid_from értékekből a legmagasabbat, ami kisebb vagy egyenlő, mint az aktuális dátum, majd ezek közül a legkisebb valid_to, ami nagyobb vagy egyenlő, mi ma. Ezt nekem nem szedte össze az sql server (tsql) egy select-ben.
Most ezt a rank() függvényt nézegettem.
[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
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. -
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...
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
-
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.
-
nyunyu
félisten
válasz bambano #4737 üzenetére
Van amikor a számítási/lekérdezési sebesség fontosabb, mint a redundancia.
Ha csinálsz egy aktuális raktár nézetet, amiben összejoinolod az eredeti raktár táblát a mozgatások szummájával, és ebből dolgozik a következő lépést meghatározó lépés, akkor minden egyes lépés kiértékelésénél a DBnek egyesével újra kell számolnia az eddigi lépések eredményét, ahelyett, hogy a letárolt köztes értéket használná.
Ez ugyan elegáns, de nem hatékony.(Épp most kínlódunk azzal, hogy mindenféle BI riportokat kell készíteni, de többszázezer soros táblákat kell joinolni, szummázni, és az eredmény kb. 40k sor/nap.
BI meg állandóan beledöglik, amikor így-úgy szűrve belekérdez a DBben tárolt nézetbe.
Úgyhogy írhatok egy jobot, ami naponta lefuttatja a kb. egy percig futó queryt, és insert into-zza egy táblába, aztán onnan fog select *-ozni a BI, nem az eddigi nézetből.)[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Szmeby
tag
válasz bambano #4743 üzenetére
Szerintem ez csak egy házifeladat.
Már eleve életszerűtlen, hogy egy rakás fontos dolgot nem vesz figyelembe. Illene ellenőrizni, hogy a teljes rendszer egyenlege egyáltalán pozitív-e. Ha nem, akkor el kell dönteni, hogy inkább a kis hiánnyal rendelkező üzletek készletét optimalizáljuk és hagyjuk a nagy hiánnyal küzdő üzletet megdögleni. Vagy a nagy hiányra összpontosítunk és a kis hiánnyal rendelkező üzletek majd megoldáják valahogy. Teljesen más megközelítést igényel a két üzleti igény.
Ha feltételezzük, hogy a teljes egyenleg pozitív, akkor is kell egy korlát, ami alatt egyszerűen nem éri meg megmozdulni. Továbbá sokkal jobb minden üzlet készletét egy átlagos érték felé közelíteni. Vagyis ne a 0 hiány, 0 többlet legyen a cél, hiszen, ahogy te is mondtad, a raktárkészlet állandóan forog: ha csak a nullát tűzzük ki célul, akkor az első vásárláskor újra negatívba fordul, ami optimalizálási igényt kényszerít ki... abszolúte nem hatékony.
De még az átlagos szint sem feltétlenül optimális, hiszen egyes üzletek forgalma historikusan nagyobb, másoké kisebb, így érdemes ez alapján egy átlagtól való korrekciót alkalmazni. Ami aztán további problémákat szül, mivel egy tűpontosságúra optimalizált rendszerben - amennyiben az ember elfelejt gondoskodni az utánpótlásról - nagyon könnyen a teljes rendszer szintjén fellépő hiány alakulhat ki nagyjából ugyanabban a pillanatban.
A feladat nem veszi figyelembe az üzletek egymástól való fizikai távolságát, a megközelíthetőséget. Nagyon szépen hangzik, hogy egy db procedure megmondja, hogy a kettes id-jú üzletből vigyünk át 50 bizbazt a 14-es id-jú üzletbe, de ha ezek a város két végén helyezkednek el, akkor az ész nélküli ide-oda szállítgatás felzabálja a profitot. Arról nem is beszélve, hogy az ezt intéző munkavállalók azt fogják kérdezgetni, hogy ki volt az az idióta, aki ezt így kitalálta... és teljesen jogosan fogják megkérdőjelezni az értelmét.
A való életben ennél sokkal komplexebb feladat egy elosztott raktárkészlet optimális fenntartása, marhára nem egy temptáblával megoldható probléma. Mármint megoldható, csak az olyan is lesz. Ízlés dolga, kinek mit vesz be a gyomra ugye.
[ Szerkesztve ]
-
nyunyu
félisten
válasz bambano #4835 üzenetére
Ezzel viszont vissza is kanyarodtunk a kurzoron végigiterálós megoldáshoz, amit macerásabb megírni, mint az előbbi jólfésült selectet
nagy vonalakban valami ilyesmi:
declare
cursor c is
select regexp
from regexptabla
order by gyakorisag desc;
r varchar2(100);
begin
truncate temptabla;
open c
loop
fetch c into r;
exit when c%NOTFOUND;
insert into temptabla (voltmar)
select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null
and e.ertek ~ r;
end loop;
close c;
select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null;
end;(Nem vágom a postgre szintaxisát.)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
-
nyunyu
félisten
válasz bambano #4956 üzenetére
mondjuk az is relatív, hogy kinek mi a nagy adatbázis. a postgesql párszázmillió rekorddal még szépen elgurul
8 éve próbálkoztam az egyik mobilszolgáltató adattárházán dolgozni, aztán a DB műveletek query planjét logoló táblából (~napi 10 millió rekord?) kellett volna adatokat kinyernem egy adatvizualizációs projekthez.
Próbaképpen lekértem negyedórányi adatot, erre 10 perccel később jött a teradata üzemeltető leordítani a hajamat, hogy ilyet ne merjek még egyszer lekérdezni, mert letérdelt tőle a 24 node-os DWH, alig bírták kilőni a querymet.
Pedig előtte direkt megnéztem, milyen indexek vannak a táblán, meg mekkora a várható eredményhalmaz mérete, nehogy egyszerre túl sokat akarjak lekérdezni...
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Taci
addikt
válasz bambano #4956 üzenetére
Jelenleg egy lokál gépen futó DesktopServer nevű környeztet használok a fejlesztésre. Itt MariaDB van használatban.
Ha van valakinek egy szabad 5 perce, csak akkor olvasson tovább.
Ez egy "itthoni tanulós projekt", semmi több. Érdekelt a téma, így elkezdtem egy weblapot készíteni 6 hónappal ezelőtt. De ekkor kezdtem el csak az alap dolgokon felül használni mindent, ami kell hozzá: HTML, CSS, JS, PHP, SQL.
Nagyon szépen haladtam mindennel, 6 hónapja minden szabadidőmet beleöltem, és most már úgy láttam, 2 héten belül készen vagyok, és költözhetek a kis projektemmel a szolgáltatóhoz: Versanus, velük van pozitív tapasztalatom korábbról. Nem tudom, hogy ott milyen adatbáziskezelő van.
Na szóval örültem, hogy végre a kis projektemet a "nagyvilág elé tárhatom" (értsd: rokonok és kollégák ), és a todo-listám egyik utolsó eleme volt, hogy utánakérdezzek, hogy a lekérdezéseim nem pazarólak-e.
És mint kiderült, sajnos rossz logika mentén építettem fel az egész adatbázist. És az a baj, hogy 6 hónapja amióta csinálom, erre a logikára épül minden de minden. Tegnap átnéztem a kódjaimat, nyilván az új típusú (1 db) táblát könnyen létrehoztam, a tartalomfeltöltő php kódot is könnyen átírtam az ajánlás alapján, hogy a több tábla helyett egybe írjon csak, külön oszlopba pedig, hogy melyik forrásból származó bejegyzéseket tárolja.
De aztán jöttek a JS-ek, plusz a lekérdezésért felelős PHP, és ott sajnos csak nagy nehézségek és időveszteséggel tudnám csak átírni az egy táblás módszerre, hogy szépen működjön. Sajnos nem erre a logikára építettem fel, így kvázi kezdhetném előröl, mert másképp csak a régi módszer kódjait tudom "megerőszakolni", és mivel arra építettem fel mindet, sosem lesz szép tiszta igazán, csak ha előröl kezdem.
És őszintén, ez most nagyon elvette a kedvem. Tökre örültem, hogy végre 6 hónap fáradozása a számomra tök ismeretlen területen végre manifesztálódik, erre kiderült, hogy nagyjából kezdhetem előröl.
Mielőtt tényleg így döntenék, kérlek, írjátok meg, tényleg akkora gond-e, ha külön táblákban vannak az adatok.
Források szerint készítettem el őket, 1 forrás - 1 tábla. Nagyon max 15-20 forrásból fogok dolgozni. Forrásonként naponta kb. 100 bejegyzéssel.
1 bejegyzéshez tartozik egy id, egy link, egy rövidebb és egy hosszabb szöveg (300 karakter max), illetve 2 kép linkje (csak link), plusz még 2 rövidebb tartalmú szöveg (50 karakter max). Ennyi.Most már én is látom, hogy sokkal jobb lett volna az 1 tábla, mert minden bejegyzés pontosan ugyan olyan felépítési, ugyanolyan oszlopok vannak minden táblában.
Viszont a kódjaim most tökéletesen működnek, millió ellenőrzést és vizsgálatot tettem beléjük, próbáltam minden eshetőségre felkészíteni. És sajnos a sok táblás megvalósítás egyáltalán nem kompatibilis az 1 táblással, tényleg át kellene írnom mindent, JS-től kezdve PHP-kig mindent, még HTML-eket is.
És ha nem szörnyen rossz, tarthatatlan, pocsék lassú a mostani felépítés (max 15-20 tábla, napi 100 bejegyzés / tábla, tehát 2000 bejegyzés / nap, 14e bejegyzés / hét, 728e bejegyzés / év), akkor nem kezdeném előröl.
Az nagyon visszavetne, már így is elszállt a kedvem.Bocs, hogy hosszan taglaltam ezt, de kérlek, írjátok meg, valóban elengedhetetlenül szükséges-e előröl kezdenem az új szerkezettel. A rokoni/kollegális elérésekhez biztosan nem.
De később, ha a fél ország ezt olvassa majd (best case scenario ), lehet valami hátulütője a több táblás felállásnak? Ha egyszerre 5 millióan nézik az oldalt, lapoznak, futnak a lekérdezések (LIMIT 4, szóval 1 lekérdezés csak max 4 találatot ad vissza mindig), milyen negatív következményei lehetnek, ha a több táblásnál maradok? Lelassul minden mindenkinek? Vagy a szolgáltató szól rám?Ezt összefoglalnátok nekem pár gondolatban, kérlek?
Eléggé elkeseredtem most, de persze ha ez a több táblás módszer a fenti számolásokat alapul véve is tarthatatlan, és később csak problémám lenne belőle (belassulna az oldal a felhasználóknak), akkor egyelőre hagyom az egészet, és majd ha megint találok rá ennyi időt egyszer, átírom.
De ha csak a tábla karbantartása miatt lenne jobb, ha egy lenne a több helyett, akkor az nem gond, mert mindent eleve a több táblásra készítettem el.Köszönöm, és elnézést az eszméletlen hosszú posztért, de 2 sorban ezt nem lehet (vagy csak én nem tudtam) rendesen elmagyarázni.
-
Ispy
veterán
válasz bambano #5003 üzenetére
El kell indulni a legkisebb dátumtól, ha jön az első dátum, ami 60 mp-en kívül van, akkor az egy csoport és indul újra a loop. Most azon lehet vitázni, hogy kisebb mint 60 vagy kisebb egyenlő. Ha megvan minden group, akkor meg kell határozni a group min és max értéke között az eltéréseket, azokat a groupokat meg ki kell szórni, ahol count(*)=1.
Már ha felfogtam mi a feladat...nem volt egyértelmű nekem az alap def.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
kojakhu
újonc
válasz bambano #5009 üzenetére
Közben meg is írta h mi a pontos elvárás, de a kódolástól nem láttam
Itt van, ami szerintem már helyes, csak azért h hátha meg lehet mégis csinálni.
Viszont performancia miatt nem lesz használható.
Max akkor, ha valahogy a sorok számát a rekurzív részben lehet limitálni. Pl ha lehet tudni, hogy max mekkora gapek vannak a logok között (ezt is ki lehet számolni akár), vagy esetleg az előző munkámmal lehet összeszerelni úgy h az ott előálló csoportokban kell csak részcsoportokat képezni.Szóval brahiból itt az újabb SQLFiddle link
Pls valaki mindenképpen válaszoljon (ha jó a megoldás, ha nem), mert a blogon "újoncként" nem írhatok csak 1-et amíg nincs rám válasz...Setup:
create table t (dt timestamp);
-- group 1
insert into t values (current_timestamp);
insert into t values (current_timestamp + interval '10' second);
insert into t values (current_timestamp + interval '59' second);
-- group 2
insert into t values (current_timestamp + interval '70' second);
insert into t values (current_timestamp + interval '71' second);
insert into t values (current_timestamp + interval '129' second);
-- group 3
insert into t values (current_timestamp + interval '200' second);
insert into t values (current_timestamp + interval '210' second);
insert into t values (current_timestamp + interval '220' second);
insert into t values (current_timestamp + interval '259' second);
-- group 4
insert into t values (current_timestamp + interval '260' second);
insert into t values (current_timestamp + interval '261' second);Lekérdezés:
WITH RECURSIVE rd(grp, mindt) AS (
SELECT 1 AS grp
, MIN(dt)
FROM t
UNION
SELECT rd.grp+1 AS grp
, FIRST_VALUE(t.dt) OVER (ORDER BY t.dt)
FROM t, rd
WHERE t.dt >= rd.mindt + INTERVAL '1' MINUTE
) -- rd
, grpd AS (
SELECT grp
, t.*
, MIN(dt) OVER (PARTITION BY grp) mindt
, MAX(dt) OVER (PARTITION BY grp) maxdt
, COUNT(*) OVER (PARTITION BY grp) cnt
FROM rd, t
WHERE t.dt >= rd.mindt AND t.dt < rd.mindt + INTERVAL '1' MINUTE
) -- grpd
SELECT v.*
, maxdt-mindt AS grp_duration
FROM grpd AS v
ORDER BY dt[ Szerkesztve ]
Új hozzászólás Aktív témák
- Skoda, VW, Audi, Seat topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen billentyűzetet vegyek?
- Ford topik
- Távol-keleti webshopok OFF topikja (játékok, kuponok, stb.)
- Autóápolás, karbantartás, fényezés
- Viber: ingyen telefonálás a mobilodon
- Ubisoft Forward 2024 - Az összes bejelentés egy helyen
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Xbox Series X|S
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen