Új hozzászólás Aktív témák
-
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?
-
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.
-
Zalanius
tag
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.
-
Zalanius
tag
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.
-
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; -
Zalanius
tag
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.
-
Zalanius
tag
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
- Bestbuy játékok
- Kész, vége, ennyi volt: eladja tévés üzletágát a Sony
- Építő/felújító topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Fontos frissítés érkezik a OnePlus 13-ra
- WoW avagy World of Warcraft -=MMORPG=-
- Elektromos autók - motorok
- Láncfűrész topik
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- További aktív témák...
- 212 - Lenovo IdeaPad Slim 5 (16IMH9) - Intel Core U5 125H, no GPU
- 211 - Lenovo Legion 5 (15ITH6H) - Intel Core i7-11800H, RTX 3060
- 210 - Lenovo IdeaPad 5 Pro (16ARH7) - AMD Ryzen 7 6800HS, RTX 3050Ti
- 209 - Lenovo Yoga Pro 7 (14APH8) - AMD Ryzen 7 7840HS, no GPU
- 206 - Lenovo Legion Slim 7 (16IRH8) - Intel Core i7-13700H, RTX 4060
- Xiaomi Redmi Note 14 256GB, Kártyafüggetlen, 1 Év Garanciával
- Minden szoftver mellé teljesen audit és NIS2 biztos, jogilag hiteles licencigazolást adunk át!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- HP ProDesk 600 G5 i5-9500 8GB 256GB 1 év garancia
- Samsung Galaxy Z Flip 5 512GB,Újszerű,Adatkabel,12 hónap garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs