Hirdetés
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- Luck Dragon: Asszociációs játék. :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- GoodSpeed: Márkaváltás sok-sok év után
- ldave: New Game Blitz - 2025
- sziku69: Szólánc.
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- eBay-es kütyük kis pénzért
Ú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
- Path of Exile (ARPG)
- Milyen egeret válasszak?
- BestBuy topik
- Okos Otthon / Smart Home
- Konzolokról KULTURÁLT módon
- Pánik a memóriapiacon
- BestBuy ruhás topik
- alza vélemények - tapasztalatok
- Bemutatkozott a Poco X7 és X7 Pro
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- További aktív témák...
- BESZÁMÍTÁS! Apple Mac Mini 2023 M2 16GB 256GB számítógép garanciával, hibátlan működéssel
- BESZÁMÍTÁS! Apple Macbook Pro 16 2023 M3 Pro 36GB 512GB macbook garanciával hibátlan működéssel
- Proc. hibás DELL Latitude 3510 Black i3 256 SSD alkatrésznek eladó
- Huawei P40 Pro 5G 256 GB dual sim, félig hibás érintő
- Apple iPad 11 (A16) 128GB Wifi Silver 1ÉV Bontatlan
- Eladó Apple iPhone 14 Pro Max 128GB / 12 hó jótállás
- GYÖNYÖRŰ iPhone 13 mini 256GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3407, 100% Akksi
- HIBÁTLAN iPhone 13 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3732, 100% Akkumulátor
- LG 55B4 - 55" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready
- Xiaomi 15 256GB,Újszerű,Dobozával,12 hónap garanciával
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest