Hirdetés
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- CES 2026: jön az AMD CES előadása és az NVIDIA GeForce ON
- Milyen videókártyát?
- A legrosszabb CPU-k – az ExtremeTech szerint
- OLED TV topic
- Hogy is néznek ki a gépeink?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- eGPU tapasztalatok
- HiFi műszaki szemmel - sztereó hangrendszerek
- Azonnali alaplapos kérdések órája
Új hozzászólás Aktív témák
-
"Valóban a mérő azonosító karaktereiben lehet betű is.": majd valami agyhalott kitalálja, hogy legyen benne ékezetes betű, pl. tulaj neve vagy címe rövidítve, esetleg bugos utf8 konverter az adatbáziskezelőben (mint ma a debianban...
) és akkor lefekszik az egész....Egyébként a számmal is az a gond, hogyha nem tudod a határait, nem biztos, hogy találsz hozzá természetes adattípust. Akkor eltárolod stringként, és vége. Vagy jöhet olyan történet is, mint egyszeri lakcímnél, hogy beépítenek egy telket, és hirtelen a természetes szám házszámból lesz egy /b.
Soha nem tudhatod, hogy egy architect miket képes elbarkácsolni
-
Én is közüzemi cég szerűséget találgatok...
Szerintem a mérőket ki kell venni, mert stringek között keresni rosszabb, mint egész számok között, másrészt nem tudni, melyik mérő neve milyen hosszú.Archiváláson valóban érdemes gondolkodni, de a kötelező megőrzési idő, szerintem, elég nagy ahhoz, hogy archiválástól függetlenül meg lehet borítani a lekérdezéseket. Ha a jelentési teljesítmény nem jó, akkor nem jól tervezték meg az adatbázist.
Egyébként a nagy tábla a biztonsági mentéseket borítja meg leghamarabb...
-
-
Ezt biztosan nem csinálnám, mert ebből orbitális katyvasz lesz a végén.
Ha mindenáron ilyen elhibázott adatszerkezetet kell csinálni, akkor valami szabályrendszert csinálnék (fogalmam sincs, hogy a mariadb vagy a mysql tud-e ilyet, a postgresql tud), hogy ha insert történik az egyedi táblába, akkor párhuzamosan legyen egy insert az összesített táblába is. Ekkor normális adatbáziskezelő egy tranzakción belül elvégzi a két insertet és van rá reális esély, hogy nem szalad szét a két tábla.Továbbra is erőltetném azt az alapelvet, hogy adatbáziskezelésnél a redundancia rossz, menekülünk tőle, mint ördög a tömjénfüsttől.
-
fjanni
tag
Én is valami hasonlóban gondolkodtam.
Mivel ciklust hagyományos értelemben nem lehet kezelni az SQL-ben tudtommal, ezért egy eljárás használata jó megoldás lehet.
Az eljárás törzsébe teszem a mag lekérdezést, CALL -al definiálom a tábla párokat és mindegyiket meghívom. Ha lesz új táblapár akkor azt egyszerűen utánaírom.Tehát valahogy így:
DELIMITER//
CREATE or REPLACE PROCEDURE cyle_sum(IN kiln1 VARCHAR(50), IN kiln2 VARCHAR(50))BEGIN
WITH
Q1 AS (
törzs lekérdezés
FROM adatbázisnév.$kiln1
),
Q2 AS (
törzs lekérdezés
FROM adatbázisnév.$kiln2
)
SELECT *
FROM Q1
JOIN Q2 ....
ENDCALL cycle_sum(tablename1,tablename2)
UNION
CALL cycle_sum(tablename3,tablename4)Ebben több dolog van amiben bizonytalan vagyok:
- lehet-e így hivatkozni a változónévre a magban lévő FROM-ban
- ha össze akarok fűzni eredményeket akkor azt az UNION-al így kell-e megtennem
ez így lefut-e a Grafana-ban -
Lokids
addikt
A problémám az, hogy a kapott adatot nem én tárolom le, hanem az SAP kapott hozzáférést a táblához és ők töltik fel.
Én már csak a feltöltött táblához férek hozzá.
Így nem tudok konverziót végezni. De megpróbálom rávenni a küldő oldalt, hogy ezt tegyék meg. Nekik semmiből sem tartana ezt is beleírni még.Köszönöm a segítséget mindenkinek!
-
fjanni
tag
Sajnos sem a LAG, sem az EXTRACT függvényt nem ismeri a Mariadb. Egyébként Grafana lekérdezésben használnám, ahol csak azokat a mezőket kellene a selectbe betenni amit ábrázolni is akarok. Azaz ez esetben két adat kellene, az időbélyeg (ami megvan - time) és a számított eltérés az előző rekordhoz képest (a jelenlegi és az előző óraállás különbözete)
-
Louro
őstag
Én Oracle-ben találkoztam vele először. Bár azóta inkább az sql server mellett tettem le a voksom. Szerintem a legtöbb helyen elérhető.
Én úgy szoktam mondani, hogy ha 1-2 alkalommal kell, akkor performancia sokadlagos. Az eredmény legyen jó. De ha már ütemezett feladat lesz belőle, akkor megnézem a végrehajtási tervet és próbálom keresni a költséges pontokat. -
Közben szerintem sikerült megoldanom. Úgy gondolom, hogy ez egy roppant buta és favágó megoldás, de működik. NyV a fogadás eredménye (0, vagy 1). A sorszam pedig a fogadás sorszáma. Azért indul 20-ról mert az a max fogadás mennyiség egy meneten belül.
select menet,
STRING_AGG(Nyv, '') WITHIN GROUP (ORDER BY menet, sorszam) as Nyv_lista
from fogadas_tabla
group by menet
)
select top 1 menet,
case when Nyv_lista like '%11111111111111111111%' then 20
when Nyv_lista like '%1111111111111111111%' then 19
when Nyv_lista like '%111111111111111111%' then 18
when Nyv_lista like '%11111111111111111%' then 17
when Nyv_lista like '%1111111111111111%' then 16
when Nyv_lista like '%111111111111111%' then 15
when Nyv_lista like '%11111111111111%' then 14
when Nyv_lista like '%1111111111111%' then 13
when Nyv_lista like '%111111111111%' then 12
when Nyv_lista like '%11111111111%' then 11
when Nyv_lista like '%1111111111%' then 10
when Nyv_lista like '%111111111%' then 9
when Nyv_lista like '%11111111%' then 8
else 0 end as Nyero_szeria
from lek1
order by case when Nyv_lista like '%11111111111111111111%' then 20
when Nyv_lista like '%1111111111111111111%' then 19
when Nyv_lista like '%111111111111111111%' then 18
when Nyv_lista like '%11111111111111111%' then 17
when Nyv_lista like '%1111111111111111%' then 16
when Nyv_lista like '%111111111111111%' then 15
when Nyv_lista like '%11111111111111%' then 14
when Nyv_lista like '%1111111111111%' then 13
when Nyv_lista like '%111111111111%' then 12
when Nyv_lista like '%11111111111%' then 11
when Nyv_lista like '%1111111111%' then 10
when Nyv_lista like '%111111111%' then 9
when Nyv_lista like '%11111111%' then 8
else 0 end desc -
#5715
Apollo17hu
őstag
Jim74
#5713
Apollo17hu
őstag
LAG() vagy LEAD() függvénnyel megképzel 7 extra mezőt, amik az előző, az azt megelőző stb. ... és végül a héttel korábbi fogadást tartalmazzák. Az így előállt 8 mezőt összeadod egy rekordon, és ahol 8-at kapsz, ott volt a nyolcas nyerő széria (vége).
-
nyunyu
félisten
Van egy táblád, amiben van egy menet_id, egy fogadas_id, meg egy nyert mező?
8x összejoinolod önmagával, menet_id = menet_id, következő fogadas_id = előző fogadas_id+1, nyert mindig 1?
select f1.menet_id,
f1.fogadas_id kezdo_fogadas_id
from fogadas f1
join fogadas f2
on f2.menet_id = f1.menet_id
and f2.fogadas_id = f1.fogadas_id + 1
and f2.nyert = 1
join fogadas f3
on f3.menet_id = f1.menet_id
and f3.fogadas_id = f1.fogadas_id + 2
and f3.nyert = 1
join fogadas f4
on f4.menet_id = f1.menet_id
and f4.fogadas_id = f1.fogadas_id + 3
and f4.nyert = 1
join fogadas f5
on f5.menet_id = f1.menet_id
and f5.fogadas_id = f1.fogadas_id + 4
and f5.nyert = 1
...
where f1.nyert = 1; -
Ispy
nagyúr
Szerintem ilyenkor nem natív formátumban van tárolva az adat, de az sql szerver felismeri és átkonvertálja, ezért jó a datediff.
Én is tapasztaltam már sebesség problémát, amikor nvarchart simán számként használtam, ha ' jelek közé raktam javult a sebessége, de gondolom akkor a leggyorsabb, ha nem kell találgatnia a motornak az adattípust.
-
szerintem nem jó irányból közelítesz.
ha egy mezőben szöveg is lehet, akkor az nem lehet int. tehát vagy "n/a"::stringet kell visszaadnod, vagy stringgé konvertált számot. tudomásom szerint olyat egyetlen sql adatbáziskezelő se tud, hogy egy oszlop az egyik sorban string, a másikban meg szám. -
kezdosql
tag
Sajnos nem jo, mert alapertelmezesben minden jatekos es edzo a szezon kezdetetol a vegeig adott csapathoz tartozik, es a serulesek csak alkalmankent derulnek ki.
Arra jottem ra, hogy nem a szemelyek vagy a csapatok, hanem az esemenyek a fontosak, innen szemlelve lehet kezelni mindent, hiszen minden merkozes es atigazolas, stb. mind-mind esemeny.
Megis, akarhogy allok hozza a kapcsolatokhoz, mindig elakadok a szemelyek es csapatok kezelesenel.:-(
A buktato az, hogy egy esemenyhez tobb csapat ES sok szemely tartozik.
Egy csapathoz a szemelyek kozul egy vagy tobb edzo ES jatekosok tartoznak.
Az edzok kozul egy aktiv, vagy vezeto edzo, ha tobb van, a tobbi segededzo.
A jatekosok az elso merkozesig kerettagok, akkor derul ki, hogy kezdo, csere, tartalek vagy serult a statuszuk, ha egyik sem, akkor maradnak kerettagnak.Egy szemely egy esemenynel edzo VAGY jatekos VAGY biro/partjelzo lehet. (Kizaro vagy kapcsolat)
Az edzok es jatekosok mindig csapatokhoz tartoznak, a birok-partjelzok mindig fuggetlenek.
Egy szemelynek egy esemenyen csak egy szerepe lehet, de esemenyek soran akar az osszes lehetseges szerepe elofordulhat akar egy szezonon belul. Ezert a kesobbi elemzesnel nem szemelyre, hanem szemelyre ES szerepre kell keresni.
(Vagy a szerepet kell elsodlegesnek valasztani, es azon belul kell keresni a szemelyre ugy, hogy mas szerepe ne legyen a talalatok kozott.)Hihetetlen, hogy ket hete ragom a gittet, es akarhogy allok neki, sehogy se jon ossze a kapcsolati halo, pedig nyilvan itt van a megoldas az orrom elott. :-(
-
martonx
veterán
Ok, lehet hogy CROSS JOIN. Meg van még a FULL OUTER JOIN is. Viszont szerintem a JOIN-hoz az kell, hogy egyértelműen megadhasd, mit mivel kötsz össze. De most lusta vagyok utánuk olvasni, csak ötleteltem, hogy hátha segítek vele.
Ebben az esetben meg biztos, hogy vagy emberünk a béna, vagy a DB séma nevetséges, hogy ilyen kulcs nélküli mindent mindennel esetet kell lekezelni
-
Ispy
nagyúr
Tudod, sok pénz, kevés munka és gyorsan kész legyen, na ebből jó esetben kettőt választhatsz, rossz esetben meg egyett sem.
Hogy legyen egy kis segítség is: olyan nincsen, hogy egy idegen, aki tudja a gyors és sok pénz titkát az csak úgy jófejségből elárulja neked is, mert ő már gennyesre kereste magát és átment Teréz anyába. A többit a kérdező fantáziájára bízom.
-
Közben megcsináltam "favágó" módszerrel
A selectet lefuttattam top 1-re, azt kimásoltam fejléccel Excelbe. Kitöröltem az egy adatot tartalmazó sort, hogy csak a fejléc maradjon, majd elmentettem csv-be.
Utána lefuttattam a teljes select-et, azt exportáltam fejléc nélkül csv-be, utána parancssorból össze copyztam a két csv file-t.Tudom, hogy nem elegáns, de most ez volt a leggyorsabb.
-
#3918
Peter Kiss
őstag
Jim74
#3917
) és akkor lefekszik az egész....
Így nem tudok konverziót végezni. De megpróbálom rávenni a küldő oldalt, hogy ezt tegyék meg. Nekik semmiből sem tartana ezt is beleírni még.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Samsung Galaxy A54 - türelemjáték
- One otthoni szolgáltatások (TV, internet, telefon)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- CES 2026: jön az AMD CES előadása és az NVIDIA GeForce ON
- Oakley topic
- Milyen videókártyát?
- A legrosszabb CPU-k – az ExtremeTech szerint
- További aktív témák...
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i5-1135G7 4Mag 16GB/512GB FHD IPS
- Bomba ár! Lenovo ThinkPad Yoga 370 - i5-G7 I 8GB I 256SSD I 13,3" FHD Touch I W11 I Cam I Gari!
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W11 I Cam I Gari!
- HP EliteBook 850 G8 Fémházas Tartós Laptop 15,6" -65% i7-1165G7 16/512 Iris Xe FHD
- Bomba ár! Lenovo ThinkPad X390: i5-G8 I 16GB I 256-1TSSD I 13,3" FHD Touch I HDMI I Cam I W11 I Gar
- GYÖNYÖRŰ iPhone X 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3586
- GYÖNYÖRŰ iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3847
- magyar billentyűzet - 136 - Lenovo Legion Pro 7 (16IRX9H) - i9-14900HX, RTX 4080 - 4 ÉV GARANCIA!
- HIBÁTLAN iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen MS4010
- Dell Latitude 5300 13,3" FHD IPS touch, i7 8665U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest