Hirdetés
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Telekom mobilszolgáltatások
- One mobilszolgáltatások
- Google Pixel topik
- Redmi Note 15 Pro+ - több plusz, mint mínusz
- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Vivo X300 Pro – messzebbre lát, mint ameddig bírja
- Samsung Galaxy Watch7 - kötelező kör
Új hozzászólás Aktív témák
-
bambano
titán
"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
-
bambano
titán
É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...
-
-
bambano
titán
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.
-
bambano
titán
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
Hirdetés
- Weblap készítés
- Milyen TV-t vegyek?
- Milyen autót vegyek?
- Gyúrósok ide!
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Samsung LCD és LED TV-k
- Telekom mobilszolgáltatások
- Star Trek Online -=MMORPG=-
- További aktív témák...
- BESZÁMÍTÁS! 32GB G.Skill Trident Z Neo RGB 3600Mhz DDR4 memória garanciával hibátlan működéssel
- BESZÁMÍTÁS! 2TB Samsung 990 Pro Heatsink NVMe SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 2TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! MSI SUPRIM X RTX 3070 8GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Powercolor RED Devil RX 7900XTX 24GB videokártya garanciával hibátlan működéssel
- Samsung Galaxy S24 Ultra / 12/ 1TB / Kártyafüggetlen / 12HÓ Garancia
- Razer Kraken V4 X RGB Gaming Headset
- 27% - AOC C24G2AE Monitor! / 1920x1080 / 165Hz / 1ms / FreeSync
- AKCIÓ! Intel Core Ultra 5 235 14 mag 14 szál processzor garanciával hibátlan működéssel
- Apple iPhone 16 Pro Max 256GB - Kártyafüggetlen, Sivatagszín, 91% Akku - 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest