Sziasztok!

Van egy SQL (developer) lekérdezésem, viszonylag komplex, több lekérdezés UNION-nal összekapcsolva, majd a végén az egész fölé teszek egy selectet, ami alapesetben SELECT * és igény szerint aggregálom az belső rész eredményeit.

Az alábbi változókat kapom eredményként (SELECT *-ra):
[Azonosító] (példában 'Alma')
[Leíró változó1] (példában 'Piros')
[Leíró változó2] (példában 'Savanyú')
[Érték] (Példában '2')

Az azonosító aszerint szerepel egyszer, vagy többször, hogy a 2 db [Leíró változó]-ból egy, vagy több érték kapcsolódik hozzá, példa:

Alma, Piros, Savanyú, 2
Alma, Zöld, Savanyú, 4
Alma, Zöld, Édes, 8
Körte, Zöld, Édes, 1
Körte, Barna, Édes, 10
Citrom, Sárga, Savanyú, 4

Be kellene vezetnem egy olyan változót, ami aszerint vesz fel egy-egy konstans értéket (pl. "egyszer" és "többször"), hogy az egyes azonosítók egyszer, vagy többször szerepelnek a táblában, de nem jövök rá, hogyan kellene. Próbálkoztam CASE / COUNT megoldással de sehogy sem akart összejönni.

Elvárt eredménytábla:
Többször, Alma, Piros, Savanyú, 2
Többször, Alma, Zöld, Savanyú, 4
Többször, Alma, Zöld, Édes, 8
Többször, Körte, Zöld, Édes, 1
Többször, Körte, Barna, Édes, 10
Egyszer, Citrom, Sárga, Savanyú, 4

Tudnátok segíteni, merre induljak el?

[ Szerkesztve ]

SELECT
CASE
WHEN COUNT(azonosito) OVER (PARTITION BY azonosito) = 1 THEN 'Egyszer'
ELSE 'Többször'
END as akarmi,
azonosito,
leiro_1,
leiro_2,
ertek
FROM [dbo].[Orders]

Window Function-öknek nézz utána.

[ 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...

köszi, kibogarászom

hű de rég írtam ilyenket, DBASE III, 90-es évek

Tudnál segíteni, hogyan lehet az ms weboldalán értelmesen keresni?

Az általad linkelt weboldalról kizárólag az "egyszerű keresés" weboldalra van link, és ha az alsó keresőbe írok be témát, vegyesen ad excel, share point és mindenféle mást.

Most két témára keresem a választ:
Az egyik a projektes példára vonatkozik, ez alapján látszik, hogy csak nagyon bonyolult, több táblás lekérdezéssel lehet adatot felvinni, ezt akarom megérteni, de a példában nem engedi, hogy megnézzem az sql kódot, és a weboldalon nem tudok továbblépni, illetve nincsen link másik weboldalra, ami az adatbevitelt elmagyarázná.

A másik egy általános kérdés, a táblák közötti kapcsolatnál van három sor, az elsőt értelemszerűen be kell pipálni, ha két táblát összekapcsolok, de a másik kettő használata nem teljesen világos számomra. Úgy sejtem, akkor lehet belőlük probléma, ha adattörlésre kerül sor, és akkor rekurzívan törölnek másik táblákból is, de nem értem, hogyan és miért, és mi a különbség közöttük.

[ Szerkesztve ]

Friss Nyugis - akinek nem hagynak nyugtot.:-(

Üdv!

PostgreSQL-hez keresek inkrementális backup megoldást. Létezik ilyen Windowsra?

Sziasztok!

Oracle SQL-ben van 3 táblám: "A", "B" és "C". "A" és "C" között "B" kapcsolótáblaként funkcionál. Szeretném megnézni, hogy
- Vannak-e olyan rekordok, amelyek megtalálhatóak "A"-ban, de nincs hozzájuk kapcsolat "B"-ben?
- Vannak-e olyan rekordok, amelyek megtalálhatóak "C"-ben, de nincs hozzájuk kapcsolat "B"-ben?
- Vannak-e olyan kapcsolatok "B"-ben, amelyek sem "A", sem "C" egyik elemére sem mutatnak?

Egyelőre arra jutottam, hogy először csinálok egy ilyet:

"A" FULL OUTER JOIN "B",

majd a kapott halmazhoz hasonló módon hozzácsapom "C"-t:

("A" FULL OUTER JOIN "B") FULL OUTER JOIN "C".

Van ennek a mókának elegánsabb módja? Olyasmire gondolok, hogy lehet-e 3 (vagy több) táblát egy lépésben FULL OUTER JOIN kapcsolni?

[ Szerkesztve ]

Valami ilyesmire gondolsz?

select a.*, b.*, c.*
from a
full join b
on b.a_id = a.id
full join c
on c.id = b.c_id
where (a.id is not null and b.a_id is null) --A-hoz nincs B kapcsolat
or (c.id is not nll and b.c_is is null) --C-hez nincs B
or (b.a_id is not null and a.id is null and c.id is null); --B-hez nincs A, C

Mondjuk a B-hez nincs A, C rekordért egy rendes fejlesztőt seggbe kéne rúgni, hiszen pont ezért találták fel a foreign keyeket, hogy ne lehessen ilyet csinálni.

Hello IT! Have you tried turning it off and on again?

Igen, ilyesmiben gondolkodom, koszi. Ezen lehet amugy vmit optimalizalni, hogy gyorsabban fusson?

megj.: Uj helyen melozom, almomban sem gondoltam volna, hogy ennyire gany az adatbazis.

SQL adatbázis schema verziókövetésre ki mit használ? Mi most a .net database projectjét TFS-el, de szeretnénk átrakni gitre a cuccot. Azure data studioval van esetleg valakinek tapasztalata, hogy mennyire megy jó benne mondjuk egy schema compare?

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

EF Core Migration

Én kérek elnézést!

Köszi, meglesem majd mit tud.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Kérlek, segítsetek irányba állni a témában:

Úgy csináltam meg az adatbázis biztonsági mentését, hogy mivel nem tarthatok meg minden backupot, ezért a már feleseges(nek vélt) fájlokat egy idő (fájl darabszám) után nem tárolom tovább.
Mivel alapból abból indultam ki, hogy ha baj van az adatbázissal, akkor az elsősorban adatvesztést jelent, így akkor az előző mentéshez képest kisebb lesz a mentett (.sql) fájl. Ezért ha kisebb, nem menti, ha pedig nagyobb, akkor mentheti, tárolhatja, hisz' került bele új adat, ergo rendben az adatbázis. Ehhez mindig az előző mentés (tömörítés nélküli) fájlméretét veszi alapul.

De most az ötlött belém, mi van, ha az adatbázis mérete nem csökken? Nem tudom, milyen eset lehet ez, de tegyük fel (extrém példa), az én oldalamat akarják a legtöbben feltörni, sikerül is, és teledobálják saját reklámokkal. Az adatbázis mérete így nőni fog. A szkriptem viszont jelenleg csak a méretnövekedésből veszi, hogy rendben van minden az új mentéssel, ami ebben az esetben hibás következtetés lenne, így a régi (még nem "meghekkelt") mentések potenciális automatikus törlés célpontjai lesznek, és a végén használható backup nélkül maradok.

Pontosan milyen esetekre kellene felkészítenem a biztonsái mentés mechanizmusát?
Mert úgy érzem, ha csak a fájlméretet nézem, már a fenti (oké, nem túl reális) példa alapján sem jó a vizsgálatom.

Ott van ugye, ha a szolgáltatót támadják, vagy esetleg hardverhiba miatt ugrik minden adat. Erre ugye megoldás, ha felhőbe is mentek folyamatosan.

Milyen (akár reális, akár 1:1M-hoz esélyű) esetek vannak még, ahol a biztonsági mentés megléte "életet menthet"? Mert akkor úgy módosítom, mit vizsgáljon.

Köszi!

Mondok egy nem is annyira extrém példát:
Amikor kézzel mókolsz a DB-ben, és te magad hibázol. Vagy ami még rosszabb, kiderül, hogy volt egy programhiba, ami elrontotta az adatokat.
Nem igazán értem, miért neked magadnak kell a backuppal bajlódnod. Jó mondjuk 8 éve csak felhőben dolgozok...

Én kérek elnézést!

Ez a 2 példa jó, köszönöm.
Viszont ugye ha esetleg programhiba rontotta el az adatokat, az nem jelenti, hogy csökkenni fog az adatbázis mérete. Tehát a vizsgálatom nem helyes (a régi fájlok törlésére vonatkozólag), legalábbis nem elég. Bár ezt az esetet (programhiba) úgyis csak utólag lehet észrevenni.

Nem felhőben vagyok, és 5 percenként pár 100 rekord van mentve, így muszáj vagyok sűrűn backupolni. Legalább egy 2-3 órás periódusban gondolkodom. Aztán azért lenne fontos a megfelelő vizsgálat (arról, hogy nem-e egy sérült adatbázis-állaptot mentek le), mert arra gondoltam (és úgy csináltam meg), hogy másnap a legelső backupnál törli az előző napi backupokat, kivéve a legutolsót. Így a végén minden napról lesz egy valid mentésem.

De ez még sok kérdőjeles koncepció, bár minden eleme készen van már és működik, csak ahogy írtam is, arra alapoztam, hogy ha nagyobb a lementett adatbázis az előzőnél, akkor valid is. És ez így nem biztos.

Szerintem egy kicsit kevered a dolgokat. A backup nem erre való. Backupolni elég naponta egyszer (gondolj bele, amikor X TB-os DB-ket 2 óránként próbálna meg bárki menteni ) . Amire te gondolsz az inkább egyfajta tükrözés, amikor két DB-d van, és időnként a másikba átszinkronizálod az adatokat.
Illetve még olyat szoktak, hogy inkrementálisan backupolnak, így nem foglal annyi helyet.

Én kérek elnézést!

Utánanéztem, lehet-e natív eszközökkel inkrementális backupokat készíteni, és ezt a linket találtam: incremental-backup-using-mysqldump

MySQL, InnoDB, incremental backup

Akinek van tapasztalata ebben a témakörben, kérem, segítsen megérteni, mi és hogyan működik, mert egyszerűen nem áll össze.
Hosszú lesz, szóval csak ha van egy fölös 5 percetek így karácsony előtt, csak akkor álljatok neki.

A fenti linken azt írják, kell előbb egy teljes backup, aztán ahhoz képest készül majd a "különbözet" (inkrementális backup).
Követtem a leírást, a példát, el is készülnek a fájlok, de nagyon sok kérdőjel van bennem. Próbáltam végig követni, mi és miért történik, de nem értem. Összeírtam magamnak időpontokkal, hogy mikor-mi történt a rendszerben:

16:59
- összes létező log fájl (mysql-bin.0000xx) törlése (teszt szerver, csak hogy tiszta lappal induljak)
17:00
- full backup
"mysqldump" . " --skip-extended-insert --complete-insert
--single-transaction --skip-lock-tables --flush-logs --master-data=2
--user=" . $username . " --password=" . $password . " " . $dbname .
" > " . $backup_folder . $backup_filename_sql;
- létrejött: backup-20211222-1700.sql (65 MB, benne minden adat)
- létrejött: mysql-bin.000001 (1 kB)
17:02
- szerver leállítása
17:03
- szerver indítása (csak hogy lássam, mi történik ilyenkor a mysql-bin fájlokkal)
- létrejött: mysql-bin.000002 (1 kB)
- módosult: mysql-bin.000001 (nagyobb lett - 769 kB)
- kérdés: Mi íródott bele, és miért ekkor?
17:04
- módosult: mysql-bin.000002 (nagyobb lett - 770 kB)
- kérdés: Mi íródott bele, és miért ekkor?
17:10
- Adatok folyamatosan kerülnek az adatbázisba, de a 01 és 02 fájlok nem változnak.
17:20
- A 01 és 02 fájlok továbbra sem módosultak.
- kérdés: A 01, 02 stb. fájlokban a saját szkriptjeim tartalmát látom. Miért?
- kérdés: ib_logfile0, ib_logfile1 stb. Ezek milyen fájlok? 262.144 kB méretűek...
17:21
- módosult: mysql-bin.000002 (nagyobb lett - 7.212 kB)
- kérdés: Miért? Mi került bele, és miért pont most?
- kérdés: 7 MB-os fájl 20 perc után? Az előző 3 hónap teljes adatbázisa 65 MB körül van... Akkor ez mi?
22:25
- semmi változás, pedig folyamatosan kerültek be új rekordok az elmúlt 4 órában
22:27
- incremental backup
"mysqladmin" . " --user=" . $username .
" --password=" . $password . " flush-logs";
- létrejött: mysql-bin.000003 (1 kB)
- módosult: mysql-bin.000002 (nagyobb lett - 106.819 kB)
- kérdés: 107 MB? 4 órányi adat után? 65 MB a full backup 3 hónap után...
22.39
- módosult: ib_logfile0 és ib_logfile1, de a méretük az előzőekhez képest nem változott (262.144 kB), csak a fájl időbélyegzője.
- kérdés: Ezek milyen fájlok? Mi változott bennük, ha a méretük változatlan maradt?
- módosult: az ibdata1 fájl is friss időbélyegzős lett
22.41
- módosult: ib_logfile0, ib_logfile1 és ibdata1 időbélyegzője
Úgy látszik, ez a 3 fájl szinkronban frissül (legalábbis az időbélyegzők).

A full backup-hoz találtam még egy "--delete-master-logs" kapcsolót is, de az csak talán egy 1 kB körüli fájlt csinált, amiben nem volt érdemi adat, szóval azt nem is használtam.

Szóval amiket nem értek:
- 20 perc után csinált egy 7 MB-os differenciál fájlt. De az előző 3 hónap összes rekordja elfér 65 MB-ban. Akkor mi kerül 7 MB-ba 20 perc után?
- Akármelyik fájlba nézek bele (mysql-bin.0000xx), a saját szkriptjeim "tartalmát" látom. Nagyon fura. Semmilyen adat a rekordokból, csak a szkriptjeim sorai...
- A link alatt ezt írja: And we only need to save mysql-bin.000002, because it contains all changes we done after our full backup. Ebből én azt értettem (amit írt is), hogy a mysql-bin.0000xx fájlok tartalmazzák a full backup óta történt változásokat, így a fő backup mellé ezeket kell majd lementeni. De akkor a rekordokat kellene tartalmaznia, nem a szkriptjeim "kivonatát"...

Valami nálam csúszik nagyon félre? Nem értem ezt az egészet.
Úgy indultam neki, hogy full backup - töltés felhőbeli tárhelyre. Aztán inkrementális backup, kis fájlok, mennek szintén felhőbe. Aztán majd valamikor (csak példa, mondjuk hetente) újra 1 full backup, és a hét hátralévő részében inkrementális, kis fájlok.
De egyrészt ezek az inkrementális fájlok hatalmas fájlok (ahhoz képest, hogy max pár 100 rekordot tartalmaznak elvileg), másrészt, a tartalmukat sem értem.

Rosszul hívom meg a full- és inkrementális backupolást? Rossz fájlokat vizsgálok?
Mit rontok el?

Hátha valakinek van tapasztalata a témában. Már csak az utolsó lépés (backup) hiányzik ahhoz, hogy költözhessek (szolgáltatóhoz), de ez egyelőre nagyon nem áll össze.

Köszönöm előre is, ha két bejgli közt (vagy akár csak pezső után majd) van időtök ránézni.

Akkor is a saját scriptek tartalmát látod benne, amikor 7 kilo és akkor is, amikor 7 mega? Nem hinném.
Mármint lehet, hogy azt látod, de bizonyára más is van mellette, különben miért is lenne 7 mega.

Az adatbázisok nem csak nyers adatokat tárolnak, vannak benne indexek, dolgozik egy rakás átmeneti adattal, metaadattal, millióegy dologgal. Miért ne írná ki ezeket az adatokat is fájlba? Attól még lehet az ebből exportált script töredék méretű, a kettő szerintem nem zárja ki egymást.

(Amúgy semennyire sem értek az adatbázisok lelkivilágához, de számomra így logikus.)

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?

Azt hiszem, kezdem érteni.
FLUSH LOGS just closes and reopens log files

Tehát nem rajta múlik, mi kerül a logokba. Ez csak lezárja az aktuális log fájlt, és nyit egy újat.

Valahol be kell állítanom, hogy ezekbe a logokba csak az adatbázist érintő bejegyzések legyenek elmentve (rekordok, táblák stb. módosításai, létrehozása stb.)

De ha már ezt így eddig összeraktam, hátha meglesz az is.
Persze ha valaki tudja a választ, kérem, írja meg.

Bocsánat az előbbi regényért, de nagyon nem akart összeállni, és nem akartam fontos részletet kihagyni a "nyomozásból".

Végig követtem egy mysql-bin tartalmát, és azt találtam, hogy valamiért az összes cron job-om összes tartalma, rekordonként megismételve szerepel benne...

Tehát ha a full backup és az inkrementális backup között 2000 rekord került be, akkor a mysql-bin-ben 2000-szer szerepel az összes cron job összes tartalma...

A teljes sztorihoz tartozik, hogy anno, amikor elkezdtem ezt az oldalt csinálni, még WordPress-szel kezdtem, és ahhoz raktam fel egy beépülőt (WP Crontrol). A WP már rég nincs használatban, azonban a mai napig ezzel készítettem a cron jobokat, mondván, erre a tesztkörnyezetre ez tökéletesen megfelel, és majd a szolgáltatónál kitapasztalom a normál cron jobok (CPanelből) létrehozását.

Lehetséges, hogy ez a plugin kavar be? Ilyen bejegyzések vannak tonnaszámra a mysql-bin fájlokban:
UPDATE `wp_options` 
SET `option_value` = 'a:35:
{
        i:1640350382;a:1:{s:17:\"crontrol_cron_job\ ...
        i:1640350473;a:1:{s:17:\"crontrol_cron_job\ ...
        i:1640350552;a:1:{s:17:\"crontrol_cron_job\ ...
stb. az összes cron job tartalma.
Aztán ez az egész rekordonként megismételve.

Mivel ilyen tábla nem lesz (wp_options, hisz' ez WordPress-hez tartozik), gondolom, éles rendszerben (ahol WP a közelben sem lesz) ez a probléma már nem fog előjönni.

Sziasztok,

SQL developert használok, és van egy (szerintem egyszerű) probléma amit nem tudok megoldani. Autodidakta módon próbálok érvényesülni így lehet, hogy bőven hiányos a tudásom.

Szeretnék több (20-30) változót definiálni egy select előtt, amire a selecten belül hivatkozok. Minden változónak egy értéke van (lehet konstansnak kellene hívni, elnézést) a lényeg, hogy ezeket egy helyen lássam és tudjam módosítani a könnyebb követhetőség végett.

1-2 változóval még meg tudom csinálni hogy DEFINE paranncsal definiálom, de a harmadikra már elhasal.

Eddig így indítottam:

DEFINE valt1=33
DEFINE valt2=55

SELECT
table1.col1,
table1.col2*&valt1,
table1.col3*&valt2
FROM
table1

Ami működik is, de 2-nél több DEFINE-nél "missing right parenthesis" hibaüzenetet kapok, pedig a szintaxis elvileg jó.

Hogy kell ezt szakszerűen összehozni? Érdekes módon erre nem találok példát google kereséssel sem.

szia,
és milyen hibát kapsz? Mert nálam tökéletesen működik

(Sorry, csak szenzitív adatot találtam hirtelen )

Sima ügy, anonim blokk elé írsz egy declaret:
declare
v_valt1 number := 33;
v_valt2 number := 55;
begin
SELECT
table1.col1,
table1.col2 * v_valt1,
table1.col3 * v_valt2
FROM
table1;
end;

Mégsem ilyen egyszerű, mert anonim blokkban nem lehet sima select (ahogy eljárás törzsben sem), várja az into táblanevet, hogy milyen táblába irányítsa a kimenetet.

Max úgy működhetne, hogy CTASt írsz a törzsbe:
declare
v_valt1 number := 33;
v_valt2 number := 55;
begin
CREATE TABLE new_table AS
SELECT
table1.col1,
table1.col2 * v_valt1,
table1.col3 * v_valt2
FROM
table1;
end;

aztán miután lefutott, akkor le tudod kérdezni egy select * from new_table;-val az eredményt.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Eljátszottam vele dummy adatokon és tényleg működött hárommal is, majd utána az éles lekérdezésben is amit nem értek, mert eddig éles táblákon "missing right parenthesis" hibát dobott, annak ellenére, hogy a forma biztosan (murphy nyilván, de ellenőriztem) jónak kellett legyen, mert egymás alá másoltam háromszor ugyanazt a blokkot, csak 3 különböző define által előírt paraméter változott.

Murphy törvénye, valamit nyilván benézhettem mégis, ez a megerősítés viszont átlendített, hogy működnie kellene, nincs limitáció (nem találtam róla semmit a neten, ezzel kezdtem a keresést). Köszi!

@nyunyu: Create table jogom nincs, csak lekérdezni (select) tudok. Próbáltam volna én is declare felé elindulni, kínomban már with-eltem elé egy táblát de persze egyik sem működött. Köszi a visszajelzést neked is.

megvan a megoldás, nem szabad kommentet tenni a DEFINE sorok mögé, mert attól fut hibára.

komment nélkül rendesen fut.

kipróbálnád a kedvemért, hogy ad-e hibát, ha raksz kommentet a define mögé, de a változó értékét idézőjelek közé rakod?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

kipróbáltam, működik " és ' -vel is, lefut, és ránézésre helyes értéket ad.

Sziasztok!

Szeretném mérni, hogy egy-egy linkre az oldalamon mennyien kattintanak (és erre építve új menüpontokat létrehozni, tehát ezek a számok új query-khez kellenek majd).

Elsőre azt gondoltam ki, hogy minden linkhez <a href teszek egy onclick eseményt, ami minden rákattintásnál (ellenőrzés után) beír majd egy ehhez létrehozott táblába: a link id-jához tartozó számlálót megemeli eggyel.
Tehát lenne egy clicks tábla, abban egy id, egy link_id és egy clicks_counter mező.
Kattintás, link_id = xyz, megnézi, ez benne van-e a clicks táblában, ha igen, akkor clicks_counter = clicks_counter + 1.

Van ennél egyszerűbb, szebb, jobb megoldás?
Csak azért kérdezem, mert az is eszembe jutott, mi van akkor, ha mondjuk 2 user pont ugyanakkor kattint ugyanarra a linkre. Mondjuk eddig 0 volt az értéke a counterének, megy egyszerre a 2 query, mindkettőnek azt mondja, hogy clicks_counter = 0, így mind a kettő 1-re fogja állítani. Vagy ezt okosan lekezeli az SQL?
Vagy máshogy kell ezt lekezelnem?

Köszi a tippeket előre is.

Erre való a Google Analytics.

Én kérek elnézést!

Nem saját link egyik sem, mind kifelé mutat, és 5 percenként jön pár 20-50-100 új.
Pl.:
<a href="https://mobilarena.hu/tema/sql-kerdes/friss.html"
target="_blank" rel="noopener noreferrer">SQL kérdések</a>

Azt, hogy melyikre hányszor kattintanak, csak saját kódon belül tudom mérni. (Vagy nem tudom jól használni a Google toolját. )

De akárhogy is, ott is ugyanaz lenne a helyzet a végén (Google adatbázisa), ott is van egy számláló egy rekordhoz, amit emelni kell.
Simán csak egy update?

UPDATE clicks SET clicks_counter = clicks_counter + 1 WHERE link_id = 123

Vagy van ennek jobb módja is? Mert nem tudom, mennyire "jó" ha folyamatosan update van a táblán (még ha erre is van kitalálva).

azért a zárolás meg a tranzakció szeparáció témakört el kellene olvasnod az adatbáziskezelőd gyártója által írt doksiban.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Tök mindegy hova mutat a link, ha a te kódodban van
Google Analytics erre a megoldás, saját kókányolás helyett.

Én kérek elnézést!

az alap probléma, hogy a google cuccait rendes böngészőben tiltják.
mondjuk a saját kódját is.

az a megoldás, ha a link a saját webjére mutat és redirectel a célra.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Annyira szeretném érteni, amit írtok, de csak fejek jönnek elő belőlem (meg rengeteg kérdés).

Google Analytics erre a megoldás, saját kókányolás helyett.
Szeretnék egy menüpontot, hogy pl. "Legolvasottabb cikkek". De az nem világos, hogy hogyan lehet jobb az Analytics-es adat, mint a saját szerveren tárolt. Vagy van rá mód, hogy direktben elérjem ezt az adatot (Google), és be tudja építeni egy query részeként? Tehát hogy pl. rendezze sorba a cikkeket aszerint, hányszor voltak megnyitva (aka. Legolvasottabb cikkek). Mert csak erre kellene.

az a megoldás, ha a link a saját webjére mutat és redirectel a célra.
Ezt elmagyaráznád, kérlek, hogy miért jó? Szeretném megérteni, hogy aztán implementálni tudjam. (Ez offtopic ide, ezért rakom off-ba, de nagyon szeretném érteni.)
Így hirtelen ami eszembe jutott, hogy külső linkekkel operál az a hírkereső. Meg is néztem gyorsan, ott ez hogyan van megoldva.

Egy példa (direkt nem alakítom linkké):
https://rd.hirkereso.hu/rd/39891270?place=6544&partner=hirkereso&url=https%3A%2F%2Fprohardver.hu%2Fhir%2Fjon_lg_elso_hibrid_projektora.html

Ez ide dob tovább:
https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.html

Megköszönném, ha lenne annyi türelmed, hogy pár szóban elmagyarázod, hogy ez a link miért így épül fel. Pl. itt miért kell az "rd" aldomain? redirect, gondolom, de ez miért kell?

https://rd.hirkereso.hu/rd/39891270
Ez is ugyanoda továbbít, már a többi rész nélkül is. (és minden más cikkhez is van egy ilyen "redirect-id") Akkor miért kell a többi rész? Nem is igazán értem, bár ez gondolom a saját kódjához kell valamiért.

És ennek a headerjében van a
Status Code: 301 (from disk cache)
location: https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.html

Viszont semmilyen forrásadatot nem látok, nem tudom, hogy továbbít.

Szóval talán az aldomain azért kellhet, mert ezekhez a külsős linkekhez csinált 1-1 saját linket a redirect aldomain-ban, és ezek a linkek 301-el továbbítják a valós cikkhez?
Ez plusz forgalmat generál neki? Vagy miért jó?

Milyen rendszert kell építeni mögé? Mit kell hogy tudjon?
És miért jobb, ha így nyílik meg a link, mintsem a direkt link? Mi a célja, szerepe?
A startlap pl. a külsős linkeket simán csak belinkeli, nincs redirect. Akkor ők rosszul csinálják?

Vagy ha nincs türelmed, kedved, természetesen azt is megértem, csak kérlek, ez esetben legalább a megfelelő keresőszavakkal segíts, hogy a megfelelő cikkeket találjam meg.

Egy általános "url redirect" sajnos nem mondja meg, hogy hogyan (és miért) kell saját weblapról saját weblapra átirányítva átirányítani. (Se másik jó pár keresés az utóbbi majd' 1 órában.)

Köszönöm.

Áhá így már értem. Bocs az elején félreértettelek. Mivel SQL-t használsz, jobb módja nincs. Más módok is vannak persze, pl. beüzemelsz egy külön NoSql-t ehhez, inmemory SQL táblát használsz, felhőben valami Queue-ba dobod be az eventeket, és majd onnan egy microservice a maga nyugijában updatelgeti a DB-t, stb...

Én kérek elnézést!

A 3xx-as HTTP kódoknál nincs konkrét tartalom (mintha csak a HTTP headert kérnéd le) és a Location header mezőben van az URL (abszolút, vagy relatív), ahova a böngészőnek tovább kell dobnia a teljes eredeti kérést. Persze az egyéb header mezőket is fel kell dolgozni (pl SetCookie, de ez a kliensen futó kód szempontjából ireleváns).

Amennyiben pl az általad említett példában az ID alapján is továbbít és nem kell a query, az lehet valami régi logika maradéka, vagy lehet benne plusz infó is, amit pl a redirect során a szerver eltárol (pl referrer link).

A konkrét esetben így néz ki egy kliens-szerver kommunikáció:
1) kliens "betölti" az alábbi oldalt:
https://rd.hirkereso.hu/rd/39891270?place=6544&partner=hirkereso&url=https%3A%2F%2Fprohardver.hu%2Fhir%2Fjon_lg_elso_hibrid_projektora.html
2) "rd.hirkereso.hu" megkapja a kérést és betölti a logikát, ami a "/rd/39891270" path feldolgozásáért felel
3) a betöltött logika megkapja az eredeti kérést a query elemekkel együtt:
/rd/39891270?place=6544&partner=hirkereso&url=https%3A%2F%2Fprohardver.hu%2Fhir%2Fjon_lg_elso_hibrid_projektora.html
4) eltárolja az adatbázisba a megfelelő elemeket, timestamp-ot és betölti annak az oldalnak az URL-jét, ahova redirect-elni kell
5) a logika nem HTTP 200 választ ad, hanem HTTP 3xx-t és a Location headerbe beállítja a redirect URL-t: https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.html
6) kliens megkapja a 302-es üzenetet és a redirect URL-t: https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.html
7) a kliens elküldi a kérést redirected URL-nek:
https://prohardver.hu/hir/jon_lg_elso_hibrid_projektora.html
8) a "prohardver.hu" betölti a "hir/jon_lg_elso_hibrid_projektora.html" path feldolgozásához szükséges logikát
9) a betöltött logika legenerálja a felhasználó számára a tartalmat és egy HTTP 200 üzenetben elküldi a kliensnek
10) a klines megjeleníti a betöltött weboldalt (illetve letölti az oldalhoz szükséges többi erőforrást)

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...

A jelenlegi megoldasod így jó

Én kérek elnézést!

Sziasztok!

Adott egy SQL adatbazisban egy tabla, ahol az elso oszlop az ID (INT), illetve van meg 10 masik oszlop varos nevekkel, a cella ertekek itt 1-100ig terjedo random szamok (km).
1. Hogyan tudok egy bizonyos ID-ra ugy raszurni, hogy az 5 legnagyobb erteku oszlop (legtobb km) ASC sorrendben legyen. (Horizontal sorting?)
2.Kivalasztani azt a recordot a tablabol, amelyik a legtobb cellat tartalmazza, aminel >= 50 az ertek?

Huh, remelem ertheto, ahogy megfogalmaztam ezt.

Koszi a segitseget elore is!

[ Szerkesztve ]

Dbfiddle példát kérek

Én kérek elnézést!

Sziasztok!

Kis segítséget szeretnék kérni. MySQL-en belül adott 3 db adattábla: project, task, join_project_task Értelem szerűen a join tábla köti össze a task táblában felsorolt feladatokat a projektekkel és a projekt táblán belül szerepelnek a projektek alapadatai. Namost a join táblán belül ugye szerepel a project_id, task_id és egy hour oszlop ami arra szolgál, hogy ide kerül be az az információ INT formában hogy az adott projekthez tartozó adott feladatot mennyi időbe telt elvégezni. A kérdés hogyan tudnám összeszámolni mondjuk egy sum-al hogy hány darab olyan projektem van ahol a projekthez tartozó összes feladat el lett végezve tehát az hour oszlop mindenütt > 0
Példa:

ezt ne countolja:
p_id=1 task_id=1 hour =1
p_id=1 task_id=2 hour =0

ezt viszont igen:
p_id=2 task_id=1 hour =1
p_id=2 task_id=2 hour =2

és ezt is:
p_id=3 task_id=2 hour =4
p_id=3 task_id=3 hour =3

így a végeredmény a példa alapján: 2
Illetve azt hogyan tudom megoldani hogy számolja össze az hour értékeit de csak azoknál a projekteknél ahol mindegyik > 0 ?
Remélem nem bonyolítottam túl a leírást.

[ Szerkesztve ]

Klasszikusan így számolod össze az órákat az összes projektre:
select p.id, p.name, sum(pt.hour) sum_hour
from project p
join project_task pt
on pt.p_id = p.id
group by p.id, p.name;

(task tábla tartalma nem ad többlet infót a feladathoz, így azt nem joinoltam feleslegesen a többihez.)

A még nem befejezett projektek kivágására az nem jó, ha beteszel egy where pt.hour>0 feltételt, mert attól még a befejezett részfeladatokat össze fogja adni.

Helyette a komplett project id-t kell kiszűrni, amihez van olyan bejegyzés, ahol a hour = 0:
select p.id, p.name, sum(pt.hour) sum_hour
from project p
join project_task pt
on pt.p_id = p.id
where p.id not in (select p_id from project_task where hour = 0)
group by p.id, p.name;

Hány project van, ami teljesen befejeződött?
select count(distinct p.id)
from project p
join project_task pt
on pt.p_id = p.id
where p.id not in (select p_id from project_task where hour = 0);

Ide nem kell a fenti group by, mivel most az összes rekordot akarod összeszámolni, és nem projektenként külön-külön.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Kezdem kapizsgálni....az a baj hogy nekem nem a task táblában tárolódik az hour -ra vonatkozó adat és mivel ez egy elég masszív program nem szeretném ezt a részét átalakítani, mert akkor egy csomó másik helyen módosítanom kellene a kódot Szóval az hour a "join_project_task" táblán belül van. Leegyszerűsítve csak arra ami nekünk most itt kell:

"project" tábla tartalma: id
"task" tábla tartalma: id, name
"join_project_task" tartalma: project_id, task_id, hours

Az hours értéke változhat, nem fix, tehát előfordulhat hogy például egy szerelés 4 óra de lehet hogy csak 2, ezért van így tárolva. Ez olyasmi mint egy digitális jelenléti ív, tehát változhat hogy 1-1 feladat mennyi idő alatt készül el, utólag kerül beírásra.

Kicsit agyaltam rajta, így az van amit említettél is, sajnos ez kiszelektálja azokat a projekteket is amikben van 0 hour érték is és annál nagyobb is:
SELECT COUNT(DISTINCT project_id) FROM join_project_task JOIN project ON project.id = join_project_task.project_id WHERE project.elements > 0 AND join_project_task.hours > 0

Ez úgy tűnik működik, csak azokat szelektálja amikben csak 0 hour értékű task van:
SELECT COUNT(DISTINCT project_id) FROM join_project_task JOIN project ON project.id = join_project_task.project_id WHERE project.elements > 0 AND join_project_task.hours = 0

Próbáltam beépíteni a not in operátort de erre 0 értéket kapok vissza:

SELECT COUNT(DISTINCT project_id) FROM join_project_task JOIN project ON project.id = join_project_task.project_id WHERE project.elements > 0 AND project.id NOT IN (SELECT project_id FROM join_project_task WHERE hours = 0)

ha a projekt táblából nem választasz mezőt, akkor minek joinolni?

select count(distinct project_id) from join_project_task
where project_id not in (
select distinct project_id from join_project_task where hour=0
);

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis