Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. SQL kérdések
  5. (kiemelt téma)
Keresés

Új hozzászólás Aktív témák

  • #4118 Zalanius tag Klub19111 #4117
    Új Válasz #4118
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz Klub19111 #4117 üzenetére

    Összekapcsolás helyett inkább bontás meg átszervezés kell ide, például a Tagok munkalap felbontása -> [Klub]; [Személy]; [Klubtagság] táblákra stb., aztán a Büntetést nyilván egy konkrét teremfoglalásra kell terhelni. Ha rögzített idősávok vannak, akkor azoknak is kell külön tábla, és így tovább. Egy ilyen sémát pikkpakk felír itt bárki, de akkor már nem valamilyen elnagyolt xlstáblából érdemes indulni, ahol a kevésbé fontos részletek hiányoznak, hanem pontosan összeszedve a fogalmakat, igényeket, különben nem éritek el azt a célt, hogy az adattár egyértelmű és áttekinthető legyen, és marad a toldozás-foltozás.

    De ez csak az egyik rész. "Ingyenes" adatbáziskezelők akadnak (sqlite, sql express, egyebek), bár üzemeltetni is kell ezeket valahol / valahogy. Oda aztán be is kell tölteni, úgymond migrálni a jelenlegi exceles állapotot, ami nem feltétlen lesz bárki által kivitelezhető. Kínálná magát egy átalakítás Access használatával, egy kicsit az Excelre hasonlító felületen, de az meg nem is annyira ingyenes. Az SQLite például igen barátságosan elfut szinte bármilyen kávédarálón, de valamilyen felhasználói felület azért kellene "fölé". Ezért a felhasználók száma is egy szempont, meg a felhasználás helye (csak lokális vagy valamilyen felhős megoldás kell). Ezek csak az első körös megjegyzések, ha olvassa majd más, hozzáírhat még vagy fél tucatnyit.

    Röviden: ez egy első látásra könnyű feladat, ami villámgyorsan el tud durvulni, és hirtelen költségek is lesznek. A kérdés: akkora már az adatmennyiség, és annyira kritikus is a helyzet, hogy megéri áldozni ezekre?

  • #4115 Zalanius tag
    Új Válasz #4115
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    "miert jonnek folyamatosan tamadasok"

    Ha volna is ilyen, alighanem azért volna, mert egy helikopter már három hónapja köröz a topic felett.

  • #4029 Zalanius tag Siriusb #4028
    Új Válasz #4029
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz Siriusb #4028 üzenetére

    CASE-hez van egy példa fent a #3905-ben.

    Ha csak az utolsó 3 hónap kellene, akkor esetleg az eredeti select is lehetne már előre így filterezve. A nem szükséges hónapoknál csak null fordulna elő. T-SQL-ben például ilyen most a [mar] oszlop, az eredeti soraid szerint:

    DECLARE @t1 TABLE (col1 char(1), col2 int, col3 varchar(10));
    INSERT @t1 VALUES ('a', 1, 'jan'),('a', 11, 'feb'),('b', 2, 'feb'),('c', 3, 'feb');

    SELECT * FROM
    (select col1 as [név], col2, col3 FROM @t1) AS src
    PIVOT (SUM(col2) FOR col3 IN ([jan],[feb], [mar])) AS pvt;

    Ha mármost ez egy dinamikus menet lesz, és az IN ( ) részt valamilyen distinctből szedjük ki előre, a jan - feb - mar sorrendért eléggé meg kell majd küzdeni. Akkor már inkább lehetne simán sorszám.

  • #3994 Zalanius tag I02S3F #3988
    Új Válasz #3994
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz I02S3F #3988 üzenetére

    Elromlani sok minden el tud, szerintem egy kicsit túl van már tágítva ez a nézőpont. Egy-egy bad sectortól még nem dőlnek össze komplett rendszerek, ilyen kapcsolat-megszakadásokra meg szinkronizációs fennforgásokra vagy más adatintegritási kihívásokra már 20-30 éve is bőven fel voltak készülve a nagy DBMS-ek, és azóta egyik se lett butább... Ha ez mélyebben érdekel, keress rá pl. erre: "SQL Server IO Internals", mert egész érdekes dolgokat lehet megtudni arról, mit milyen prioritással írnak diszkre, milyen paritásbitekkel stb. stb. Ez a mai gyakorlati felhasználástól egy eléggé távol eső terület, a fekete öves enterprise sysadminoknak talán lehet ilyen dolga szökőévente, ha nagyon nincs szerencséjük.

    Kiszámítathatatlan működés: hát ennek szerintem pont az ellenkezőjéről van itt szó. És egy tervezőnek meg üzemeltetőnek is ezt kell szem előtt tartani, egyrészt preventív módszerekkel (erőforrásterv, jogkörök, jogosultsági mátrixok) meg az ütemezett backupokkal.

  • #3986 Zalanius tag I02S3F #3981
    Új Válasz #3986
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz I02S3F #3981 üzenetére

    Accesstől függetlenül tulajdonképpen melyik szempontot gondolod problémásnak, az "egyetlen"-t? Pl. MS SQL Server esetén is egy (tipikusan) .mdf fájlban vannak a sémák és adatok, tehát a lényeg, ha eltekintünk az .ndf meg .ldf fájloktól. A sérüléses gondolatot mondjuk értem, de attól aligha volna kisebb ez a veszély, ha fel volna szeletelve több kisebb, de egyformán létfontosságú fájlra. A biztonságra persze adni kell, de különféle helyi-távoli backupok, failover clusterek stb. nem változtatnak az "egyetlen fájl" alapelven. Amiben más ez a világ, mint egy doksikönyvtárban tenyésző .accdb, hogy a mondott .mdf fájlhoz nem fér hozzá egy mezei user vagy process.

  • #3939 Zalanius tag mr.nagy #3935
    Új Válasz #3939
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz mr.nagy #3935 üzenetére

    Az ilyen "rákövetkező hét x. nap" stb. elég mókolós tud lenni, ezért ha nem megy egyből kisujjból, célszerű felírni néhány segédváltozót, azzal elbabrálni, tesztelgetni. Két példa lent:

    -- 1. Olvasmányosan
    DECLARE @bazisnap date = SYSDATETIME();
    DECLARE @napdelta int = 8; -- adjunk hozzá x napot
    DECLARE @celnap int = 6; -- a következő pénteket keressük, a péntek sorszáma 6, ez a skála 1-7 közötti
    DECLARE @eredmeny date;
    -- 8 nap múlva milyen nap lesz?
    DECLARE @x1 int = (SELECT DATEPART(dw, DATEADD(day, @napdelta, @bazisnap)));
    -- Adjuk az deltához a még hiányzó napokat, két eset lehetséges
    IF @x1 > @celnap SET @napdelta = @napdelta + 7 - (@x1 - @celnap); ELSE SET @napdelta = @napdelta + @celnap - @x1;
    SET @eredmeny = DATEADD(day, @napdelta, @bazisnap);
    -- Ellenőrizhető az összes részszámítás is, ha kell
    SELECT @eredmeny, @napdelta, @x1;


    -- 2. Kevésbé olvasmányosan
    SELECT CASE WHEN DATEPART(dw, DATEADD(day, 8, SYSDATETIME())) <= 6 THEN CONVERT(date, DATEADD(day, 8 + 6 - DATEPART(dw, DATEADD(day, 8, SYSDATETIME())), SYSDATETIME()))
    ELSE CONVERT(date, DATEADD(day, 8 + 7 - (DATEPART(dw, DATEADD(day, 8, SYSDATETIME())) - 6), SYSDATETIME()))
    END;

  • #3852 Zalanius tag kem #3850
    Új Válasz #3852
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz kem #3850 üzenetére

    Thx így már jobban értem, mi volt a cél. Reflexből a NOT IN meg NOT EXISTS variációkra gondolnék ilyen esetekben, nem erre a változatra, ezért volt furcsa, de valszeg ez csak ilyen egyéni dolog.

    Sajnos érdemi ötletem az továbbra sincs, ha itt az a probléma, hogy tökugyanaz a query hol ilyen, hol olyan eredményt ad, és közben egész biztos lehetsz benne, hogy a többi kapcsolt tábla nem variál a dolgon. Egyáltalán nem tűnik normálisnak, se az in-memory, se más db esetén.

  • #3848 Zalanius tag kem #3847
    Új Válasz #3848
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Zalanius

    tag

    válasz kem #3847 üzenetére

    Sry előre ha fura a kérdés, de left OUTER join és az exclude hogyan említhető egyszerre? Amikor utoljára ORA-ztam, az outer join pont az ellentéte volt, teljes megőrzés a bal táblára.

    Azt sem értem, hogy miért kell a vonatkozó mezőn ott a null filter, de emögött biztos van szándék.

Új hozzászólás Aktív témák