Ú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
- Amlogic S905, S912 processzoros készülékek
- Google Pixel 9 Pro XL - hét szűk esztendő
- Hitelkártyák használata, hitelkártya visszatérítés
- Mini-ITX
- Yettel topik
- Kezdő fotósok digitális fényképei
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Revolut
- Horgász topik
- További aktív témák...
- Lenovo ThinkPad T14 Gen 3:i5 1250P(12mag),16GB,512GB,14"matt TOUCH,vil.HU bill,Lenovo gari 2026.6.25
- Amazfit Gtr 3 Pro okosóra dobozával újszerű állapotban
- i3-8100 + ASUS H310M alaplap + 8GB RAM egyben (félkonfig)
- Asztali PC , R5 5500 , RX 6700 XT , 32GB RAM , 512GB NVME , 1TB HDD
- Sony PlayStation 5 Fat 825 GB eredeti doboz, gyári kontroller
- Csere-Beszámítás! Sapphire Pure RX 7900XT 20GB Videokártya! Bemutató darab!
- Bomba ár! Dell Inspiron 7400 - i7-1165G7 I 8GB I 512SSD I 14,5" 2K I HDMI I Cam I W11 I Garancia!
- ÁRGARANCIA! Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
- Fotós felszerelés - Stúdió lámpa / Softbox / Vaku
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest