Először is köszi az észrevételeket.

bambano : A fenti szerkezet csak egy kivonat. Pontosan ez volt az érvelés mögötte amit te is írsz. Ettől biztosan több lesz a karbantartandó adat. Az ehhez kapcsolódó implementáció nem akkora overhead. Inkább felhasználói oldalról volt ez vizsgálva. Hogy ne kelljen sok képernyőn keresztül kiigazodnia a user-nek, hogy karbantartsa ezeket az adatokat. Így egy képernyőn el tudja intézni. Persze az implementáció is szóba került, hogy egyszerűbb 1 képernyőt megcsinálni.
Objektíven nézve nekem ez egy új megoldás...és úgy érzem ez ellentéte a normalizálásnak.

whYz A tovább bontás az már meglévő gondolat. Igazából az egész állapot egy piszkozat. Szóval ez még nem a végleges. Sok kérdés tisztázás alatt van még.
A TYPE+ID esté type-onként lenne egyedi az ID. Ezért kell együtt PK-nak lenniük.
Én a szétbontás mellett vagyok, ahogy az ábrán is rajzoltam. Viszont látok realitást is a másik ötletben is...

nyunyu A hibernate nem kőbe vésett dolog. De abból amit írsz nekem inkább egy rosszul konfigurált és rosszul működtetett Hibernate réteg körvonalazódik... Ezt a fejlesztőkkel kell lejátszani, mert ez így nem fenntartható. Széles körben alkalmazott technológia. Nem tökéletes, semmi sem az, de viszonylag jó vélemény van róla többségében.
-----

Visszatérve a DB szerkezetére. Nem nagyon tudok érvelni a közös tábla ellen. Mondjuk kódból kell nagyon undorító dolgokat csinálni. Mert egy közös típus lesz különböző dolgokra. A pókösztönöm azt mondja ez nem egészséges hosszú távon.

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Én azt javaslom, hogy tedd le a voksodat a közös vagy a külön táblák mellett. Nincs lényegi különbség gyorsaságban, a fejlesztők/üzemeltetők életét könnyíted meg, ha egységes, és nem keveredik a két hozzáállás egy adatbázison belül.

Persze, semmiképp sem akarom keverni. Én fejlesztési oldalról vagyok érintett. A PM akivel az alapokat tesszük le meg, hát PM meg üzleti oldalról érintett. Ezért nézzük két szemszögből. Itt az a nagy kérdés, hogy mi legyen az elhatározás. Az oké, hogy egyik legyen, de melyik?

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Normalizálásnak megvan a maga helye és az ideje, de ez az eset nem tűnik annak.
Mostanában már nem annyira a tárhely (memória, vinyó, szalag...) a szűk kapacitás, mint tizenévekkel korábban, így már nem feltétlenül érdemes a normalizációval megspórolható helyre gyúrni.

Adattárházaknál például bevett szokás a csillag séma, amikor egy nagyon széles, sokmillió soros ténytáblához joinolnak sok kicsi dimenziót, viszont a dimenziótáblák tartalmát nem nagyon szokták normalizálni, hogy minél kevesebb joinnal gyorsabban lekérdezhető legyen a nagy mennyiségű adat.
Vannak olyan mondások is, hogy a dimenziókat nem ártana normalizálni, azt hívják hópehely sémának, de az általában ront a lekérdezések, adattranszformációk sebességén.

Előző projektünkből kiindulva az sem ideális, amikor tizen-huszon, alig pár rekordot tartalmazó paramétertáblát kell kerülgetned, hogy mi az amit a következő shipmentbe bele kell tenned, és mi az amit nem szabad.
Olyankor valami mindig kimarad, vagy éppen felülírod az éles beállításokat egy alsóbb környezetre érvényes teszt beállítással.
Ráadásul fél évvel később az üzemeltetési doksi írásakor már nem is emlékeztem arra, hogy kollégák melyiket mire használták, sokat úgy kellett kitúrni a kódból, amikor az üzemeltetők rákérdeztek valami egyedi beállítási lehetőségre.

Azon a projekten a fontosabb paraméterek állítására például az Üzlet kért egy képernyőt, ahol Excelben letöltheti a fontosabb paramétertáblák tartalmát, majd szerkesztés után visszatölthesse.
Azokat a táblák tartalmát például tilos volt dumpként a shipmentbe adni, nehogy felülírjuk a felhasználók beállításait.
Ha új sorok kellettek, akkor azokat élesítéskor insertekkel kellett beszúrni.

Hello IT! Have you tried turning it off and on again?

"Inkább felhasználói oldalról volt ez vizsgálva. Hogy ne kelljen sok képernyőn keresztül kiigazodnia a user-nek, hogy karbantartsa ezeket az adatokat. Így egy képernyőn el tudja intézni."

Mi köze a UI-nak a DB reprezentációhoz?

Így önmagában semmi... Az 1 képernyős karbantartást meg lehet oldani több tábla esetén is. Én csak megosztottam az érvelést amit kaptam.

nyunyu : Ez mondjuk nem adattárház lesz. Viszont mivel tervezési fázisban vagyunk ezért én próbálok minden esetleges vonatkozást megvizsgálni. Most a Hibernate is elgondolkodtatott... Ott is vannak kérdőjelek az egyesített tábla miatt.

[ Szerkesztve ]

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Sziasztok!

PostgreSQL-es kérdésem lenne, FOR ciklussal kapcsolatban:
Adott egy tábla, melyen végig akarok menni egy FOR-ral, de olyan sorrendben, hogy két mezőt vegyen figyelembe. Vannak csoport ID-k és azon belül az egyedi ID-k.
Az lenne a lényeg, hogy növekvő sorrendben menjen végig rajtuk, úgy, mint ORDER BY "ClassID", "ID".
Szerintetek ez így jó PostgreSQL-ben? Azaz helyesen írtam meg?

DO $$ 
<<first_block>>
DECLARE
i int;
BEGIN 
FOR i IN SELECT "ClassID", "ID FROM table ORDER BY "ClassID", "ID"
LOOP
END LOOP;
END first_block $$;

Futtasd le, és gyorsan kiderül

Én kérek elnézést!

Átgondoltam és kicsit máshogy közelítem meg a kérdést: adott egy tábla, melynek van egy ID mezője. Ehhez nem akarok hozzányúlni (később még szükség lehet rá). Azonban, szeretnék egy másik ID-t, ami természetesen szintén egyedi kell, hogy legyen. Erre azért van szükség, mert jelenleg nem a számomra megfelelő sorrendben vannak az adatok. Azaz, lényegében azt szeretném, hogy ORDER BY "ClassID", "Valami" ASC. Ez alapján legyen kiosztva az új ID, növekvő sorrendben.
Szerinted ezt hogyan lehetne megvalósítani a legegyszerűbben? Új táblát nem akarok, a már meglévővel kell dolgoznom.
Index-eléssel vajon megoldható? https://www.postgresql.org/docs/10/indexes-ordering.html
Ezáltal lenne egy indexem, de én egy új mezőt is akarok.
Ha megvan az index, majd csinálok egy CLUSTER-ezést: https://www.postgresql.org/docs/10/sql-cluster.html
Végül csak simán hozzáadok egy új serial mezőt, az jó megoldás lehet?

[ Szerkesztve ]

Mi volt a baj az eredeti elképzeléseddel?

FOR nem a mögé írt query által visszaadott sorrendben megy végig a sorokon, mint ahogyan a kurzorok tennék? De.

Indexelős ötleted nagyon elborult, egyrészt nehéz megvalósítani, pl. mi van akkor, ha jön egy új elem a táblába, akkor minden sort megupdatelsz az aktuális sorrend alapján?
Iszonyúan nagy overheadet produkálnának az ehhez szükséges triggerek.

Ha csak annyi lenne a kérdés, hogyan tudod megmondani egy sorról, hogy ő valamilyen rendezés szerint hanyadik a táblában, akkor a row_number() over (order by x,y) függvényt tudod használni.

Egyébként meg a relációs adatbázisok mindig halmazokkal dolgoznak, nem egy-egy elemmel, így a más programnyelvek procedurális gondolkozásmódja (ciklusok, kurzorok...) SQLben sosem ad jó teljesítményt.
Próbálj inkább úgy gondolkozni, hogyan lehet egy queryvel az összes adatot egyszerre frissíteni/beszúrni.

Előző projekten amúgy belefutottam hasonlóba, mint amit most szeretnél.
Örököltem egy kódot, ami egy táblából csinált egy rendezett kurzort, majd azon ment végig egyesével, és dinamikus SQLben kért új értéket egy szekvenciából, majd updatelte rá a tábla soraira, kvázi új indexet vezetett be.
Persze, hogy 15000 sor esetén húsz percig szöszmötölt rajta az Oracle.
Megoldás az lett, hogy egy segédtáblába leválogattam a fő tábla azonosítóit, meg a row_number() over (order by x,y) rn-t, aztán következett egy jól irányzott merge a fő táblára.
Egyből lefut 10 másodperc alatt...

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Érdekelne a ti megoldásotok postgresql-ben:
Előre adott n-re annak a napnak a dátuma EEEEHHNN formátumban, amelyik a lekérdezéstől számítva az n. munkanap úgy, hogy a lekérdezés napja a nulladik, a másnapja az első. Segítségként van egy calendar nevű tábla, amiben rekordonként benne vannak az ünnepnapok és a munkanap áthelyezések, egy date nevű mezőben.

tehát ha ma lefuttatom 6 napra, akkor 20200415-öt ad eredményül.

kösz

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Fognám a calendar táblát, raknék rá egy "nagyobb, mint a bemenő dátum" ÉS "legyen munkanap" szűrést, majd a kapott halmazon valamilyen rank() függvénnyel (van ilyen postgresql-ben?) egy sorszám mezőt generálnék, ami dátum szerint növekvő sorrendben osztaná ki a sorszámot. Ahol a sorszám n, az a keresett dátum.

Ehhez mondjuk az is kell, hogy az ünnepnapokból és a munkanap áthelyezésekből rendelkezésre álljon egy munkanap flag ['I', 'N'] is. Ha ilyen nincs, azt mondjuk egy CASE WHEN-nel külön le kell még kezelni.

a calendarban csak a rendkívüli munkarend napjai vannak benne.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Jaaa... Az szívás. Ahol én dolgoztam, ott a calendar tábla minden naptári napot tartalmazott talán 1900-tól 2040-ig. Külön flag volt a munkanapokra, hóvégekre, hét melyik napja, mi a köv. munkanap stb.

Szóval akkor egy ilyen segédtáblát kellene megképezni, és felhasználni ahhoz, amit fentebb írtam. Legyen mondjuk ez a calendar_2! Valahogy így állítanám elő calendar_2 -t:

1. Keresnék egy számláló táblát az adatbázisban, ami 0 és egy nagyon nagy szám között tartalmazza az egész számokat. (Ha nincs ilyen, akkor tetszőleges táblán row_number-t képeznék, és azt használnám.)
2. A számláló tábla rekordjaihoz megképezném a calendar_day mezőt, ami a naptári napokat tartalmazza. Az 1. naptári nap a bemenő dátum, az összes többi pedig ez a dátum növelve a számlálóban lévő értékkel (date_add, ha van ilyen postgresql-ben).
3. Szintén új mezőben megjelölném a szombatokat és vasárnapokat. (modulo 7 eredménye alapján)
4. A 2. pontban létrehozott listához gyengén (LEFT JOIN) hozzákötném a calendar táblát, amiben csak a rendkívüli munkarend napjai vannak benne.
5. A 3. és 4. pontban lévő információ felhasználásával létre lehetne hozni a végleges workday_fl mezőt.

Így állna elő a calendar_2 halmaz, amiből calendar_day-t és workday_fl-et lehetne felhasználni a megoldáshoz.

ennél sokkal egyszerűbbet szeretnék.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

DBfiddle-be dobd be légyszi ezt a táblát, hagy játszunk vele

Én kérek elnézést!

Oracle:
with extra_nap as (
select '20200410' datum, '7' nap from dual
union
select '20200413' datum, '7' nap from dual
union
select '20200501' datum, '7' nap from dual),
szamok as (
select level l
from dual
connect by level <= 1000),
datumok as
(select to_char(sysdate+l,'yyyymmdd') datum,
case when nvl(e.nap, to_char(sysdate+l,'d')) in ('1','2','3','4','5') --hétfő..péntek
then 'Y'
else 'N'
end munkanap
from szamok l
left join extra_nap e
on e.datum=to_char(sysdate+l,'yyyymmdd'))
select datum, row_number() over (order by datum) rn
from datumok
where munkanap='Y';

Extra_nap "táblába" felvettem a nagypénteket, húsvéthétfőt, május elsejét vasárnapi munkarenddel.
Aztán legenerálom a következő 1000 nap dátumát, és melléteszek egy munkanap flaget, ami az extra_napban beállítottból vagy a hanyadik nap a héten értéktől függ.
Végül leválogatom a munkanapokat és melléteszek egy sorszámot, hogy ő hanyadik.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

oh my god de ronda...
szerencsére nem oracle-ről van szó...

a gondolatmeneted az, amit én is kitaláltam.

logikai kifejezést char-ra konvertálni, majd vissza logikaivá, annak nem sok értelmét látom.

köszönöm uram, hogy nekem postgresql jutott

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

én erre jutottam:
1. generálom a következő napok dátumait
2. ebből kidobom, ami szerepel a calendar táblában
3. kilistázom a maradékból a munkanapokat, sorbarendezve
4. a listából az n. elemet lekérdezem

amiben nagyon más: van generátor függvény, ami többek között dátum típusra is működik, és az ünnepeket egy not in subselect halmazzal szedem ki.

kb. így néz ki postgresql-ben:
select l.nap,date_part('dow',l.nap),
     to_char(l.nap,'YYYYMMDD') as kompaktdatum from
(select date_trunc('day',generate_series(now()+'1 day'::interval,
    now()+'30 days'::interval,'1 day'::interval)) as nap ) l
 where l.nap not in (select distinct date from calendar where date>now()
and  date<now()+'30 days'::interval)
and date_part('dow',l.nap) in (1,2,3,4,5) order by l.nap limit 1 offset 5;

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

logikáját tekintve valóban az, amit nyunyu írt, de ezt én is leírtam már (#4469) (eltekintve attól, amennyivel butább az oracle... ) . amit te írtál, az teljesen más. te keresnél egy számolótáblát az adatbázisban, amit nem tudok értelmezni, és azzal számolnál. ezzel szemben a postgresql (ami kikötés volt), on the fly képes sorozatokat generálni és record-setként kezelni. a hétvégéket nem modulo 7 alapján számolja, ami egyébként is lehetetlen, mert a kiinduló napnál hiába akarnál modulo7-et számolni, hanem a beépített naptár funkcióval, ahogy nyunyu is.

lelassulhat? miért is?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem elég azt nézni, hogy benne van-e a dátum a calendarban, hanem azt is kéne nézni, hogy az extra nap milyen napnak számít, különben elveszted a soknapos ünnepek körül elcserélt szombati munkanapokat.
Ezért volt plusz egy oszlop az ügyfeleinknél használt naptár táblákban, ahova a munkanapcserés szombatokat is fel kellett vennem péntek értékkel, előtte pénteket meg csütörtökkel, amikor egy évre előre felvettem az ünnepnapokat.

NOT IN vs LEFT JOIN?
Annak idején úgy tanultuk, hogy jobb az anti join teljesítménye, de nem tudom ez a mai DB kezelőknél mennyire áll még fenn.
Oracle optimalizálója alapból anti joinná alakítja a not in-t, hacsak nem tiltod meg neki, így ott már nincs különbség teljesítményben.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

"NOT IN vs LEFT JOIN?": értem, amit írsz, de.
a calendar tábla évi nagyságrendileg 20 rekorddal bővül, és mivel a subselectben van dátumra való korlátozás, így amikor ez végrehajtódik, akkor néhány rekord kerül a not in (...) -be. ennyivel boldoguljon már.

annak utána fogok járni, hogy az áthelyezett szombat az én problémám szempontjából minek számít. kösz a felvetést.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Helló emberek, iránymutatást szeretnék kérni. Mivel IoT rendszerről (Raspberry Pi) van szó, minden megspórolt millisec számít.

Adott egy már jól működő service, de ami még debug módban megy, ezért rengeteget loggol file-ba (egyelőre kell is, az alapján csiszolom), viszont minden nap végén a log file-t kiürítené, tartalmát SQLite adattáblába zsuppolná (keresés, kiértékelések miatt). Sajnos egyelőre vannak logbejegyzések, amiket bent hagynánk a fileban, és nem lenne jó naponta újra és újra beírni az adatbázisba, ezért egyszerűen tárolunk ott egy MD5 hasht is (vizsgálva, hogy a hash bent van-e már az adatbázisban). A helyzetet "bonyolítja", hogy tranzakcióval megy a beírás (napi 200-1000 log tranzakció nélküli beírása [csak az adatbázisművelet] 1-2 sec, tranzakcióval 40-80 ms).

Hogy lehet a legjobban, legelegánsabban megoldani?
- letárolás előtt a hash értékek kiolvasása egy tömmbe/listába programozottan (C#)?
- INSERT helyett SELECT(?) + INSERT annak csekkolására, hogy már bent van-e a hash, a db-re bízva? Ha igen, itt kérnék iránymutatást, fogalmam sincs, ez miképp kivitelezhető egy tranzakció belsejében, a COMMIT parancsot megelőzően.

Az első pont fizikailag készen van, működik is, csak nem tudom, ez így mennyire vehető jó megoldásnak egy IoT rendszernél.

Javaslatot szeretnék kérni!

Mekkora az MD5 hash mérete? Mert ha nagyon nagy akkor le kéne cserélni egy INT-re mint kulcs. Azzal gyorsabb keresni.
Pontosan mit/hogy szeretnél tárolni az adatbázisban?
Kicsit homályos az a rész, hogy nap végén beszúrod a napi log bejegyzéseket egy táblába, majd kiüríted a logot néhány bejegyzés kivételével és másnap újból ugyanabba a fájlba írnál új logokat? Miért nem másolod el egy másik fájlba azokat amit nem akartsz törölni és akkor a log fájl tartalmából mindig insert lenne csak?
Amúgy ami a kérdéseidet illeti (bár nem ismerem az SQLiteot):
- tennék egy indexet a kulcsra, úgy a leggyorsabb keresni illetve kéne rá a primary key megszorítás és akkor nem szúrhatná be ugyanazt a sort kétszer.
- Mindenképpen INSERT rögtön, nem kell SELECT előtte és valamilyen try - catch jellegű dolog köré elkpani a hibaüzenetet. BTW, UPDATE lenne a benn lévő soron vagy nem?

Mekkora az MD5 hash mérete?
Ezt nem értem Simán a normál MD5 16 bájtos mérete, hexában.

Miért nem másolod el egy másik fájlba azokat amit nem akartsz törölni [...]?
Alapvetően az lett volna, hogy nap végén: logs.txt -> logs001.txt, de külső elérés kell a loghoz, ezért (+ a kereshetőség miatt) a DB.

Most van egy AI PK, de az a fájlbéli logbejegyzéstől független. Arra is gondoltam, hogy hátha lenne egy int alapú hash algoritmus, de itt is fontos a gyorsaság (az MD5 előállítása minimális erőforrást igényel), a hash-re csak az adatbázisba írás miatt van szükség, a feladat többi szemszögéből irreleváns.

Így néz ki a tábla schema:
CREATE TABLE "logs" (
 "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
"level" INTEGER,
 "tstamp" TEXT,
 "message" TEXT,
 "location" TEXT,
 "userid" TEXT,
 "hash" TEXT
);

A logfájl mindegyik sora egy határoló string alapján kerül feltördelésre, a log level pedig a megfelelő string indexe lesz (NONE->0, ERROR->1, DEBUG->2, ...).

Egy log sor így néz ki:
DEBUG - 2020-04-05 16:00:04 - No IP change detected, no need to update - [itt az adott namespace.class.method van] - [devicename/userid]

Tranzakcióra nincs esetleg valami (sematikusan) ilyesmi?
IF SELECT ...
INSERT INTO ...
ENDIF

A hasht tároló oszlopra rakj rá egy unique megszorítást, és akkor magától hibát dob, ha már bent lévő értéket próbálsz megadni:

CREATE TABLE "logs" (
"id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
"level" INTEGER,
"tstamp" TEXT,
"message" TEXT,
"location" TEXT,
"userid" TEXT,
"hash" TEXT UNIQUE
);

Nem vágom az SQLiteot, de az insert szintaxisát elnézve lehet benne olyan upsertet írni, hogy:
insert or ignore into tábla values (értékek) on conflict do nothing;

Ekkor figyelmen kívül hagyja a hibára futó insertet, és nem hajtja végre.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Jogos, azt zavart be, hogy 32 karakteren ábrázolják/tárolják, nem pedig egy 128 bites számként.

Viszont még az is eszembe jutott, hogy ha valahol letárolod, hogy mi volt a legnagyobb dátum amit még beszúrtál, akkor a log file olvasáskor figyelmen kívül hagyhatsz minden olyan sort ami annál régebbi. Az újabbakat meg simán inzertálod. Csak ne felejtsd el letárolni az új MaxRowLoadDate-et a log feldolgozás végén.

erre való a logrotate.
egyszerűen aminek maradni kell, azt átmozgatod egy másik fájlba, esetleg a nevébe dátumot rakva.
minden más bonyolultabb.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Sziasztok!

Adott két SQL Server 2008 R2. A kettő össze van kapcsolva (Linked Server). Az lenne a kérdésem, hogy ha a két szerver között akarok olyat, hogy A szerverről másolja át a táblákat napi szinten a B szerverre, mint egy backup, akkor melyik a gyorsabb a megoldás? T-SQL vagy a SSIS?

Jelenleg az előbbi van alkalmazásban, de ha tudok időt nyerni, akkor annak örülnék. Rengeteget gugliztam már a témában, de sajna nem találtam egyértelmű választ.

Köszi előre is a válaszokat!

Mess with the best / Die like the rest

SQL Szerver replikáció nem játszik? Nem használtam sose. De ez elég régóta egy elérhető feature. Szóval ha olyat kellene csinálnom amit írtál, én ezt (a beépített replikációt) nézném meg először, hogy hogy működik.
Amúgy pontosan mi a lassú? Konkrétan a rekordok átmásolása, vagy nagy a késleltetés (latency) a két szerveren lévő adatok állapota között?
SSIS-t sem használtam , de azzal is megpróbálnám, ha ez csak olyan batch/bulk jellegű másolás lenne. Általában ezek az integrációs eszközök elég jók.

Több 20gb+ tábla is van az átmásolandók között, ami emiatt több órát igényel. Szimplán csak át kell másolni a tábla teljes tartalmát. (Az oka, hogy ne az éles környezetet terheljük elemzési célból, hanem egy másolatot. Egy kartéziánus szorzat és megfektetjük az élest és hamar tartós szabadságra küldenek . )

Lassúnak nem biztos, hogy lassú, de ha egy kicsit is tudok spórolni, akkor én hajlamos vagyok időt tenni bele. Kicsit kattanásom, hogy ha lehet jobban, akkor miért ne.

Az SQL replikációról megkérdezem a DBA-nkat. Én ezt nem használtam. Ennek is kicsit utánajárok

Mess with the best / Die like the rest

Replikáció erre való, hogy ha megváltozik egy adat, akkor a változás automatikusan át legyen víve a másolatra is.

Persze arra oda kell figyelni, hogy a táblák egyedi azonosítóit populáló szekvenciákat nem szokta szinkronizálni, így pl. ha kiesik az eredeti adatbázis, és ideiglenesen a replikát akarod használni helyette, akkor manuálisan léptetned kell a másolat DBben lévő szekvenciákat, hogy nagyobb értékről induljanak, mint a táblában lévő aktuális ID, különben egyedi kulcs sértést kapsz, amikor írni próbál a rendszer a replikába.
(aztán a kiesett eredeti DBre visszaálláskor is el lehet ezzel játszani.)

Nyilván a replikációt elindítani sem munkaidőben kell, ha akkorák a tábláid, hiszen jó pár óráig eltarthat, mire nulláról felépíti a másolatot.

Kollégáimnak annó elég sok bajuk volt az SQL Server 2000 replikációjával, de a 2005, aztán a 2008 már jóval stabilabban működött.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Köszi az infót. Általában éjfél után fél perccel indítjuk jelenleg is az átmásolást és van, hogy 7-ig is eltart :/ Az éles is lassan 1 terra. De ennek egy töredékéről készítünk tükörmásolatot.

Úgyis lassan várható egy kis fejlesztés a 2012-re. Lehet ezt a repikációt bedobom. A DBA-nk szerencsére jó szaki. Lehet tud is erről, csak több, mint 10 éve nem nyúltak a jelenlegi rendszerhez :/

Köszi mindkettőtöknek!

Mess with the best / Die like the rest

Amúgy miért napi 1x replikáltok? Miért nem megy mondjuk (1-3) óránként csak az aktuális adat?

Amire nekünk kell, arra jó a T-1 napi adat. Így is csoda, hogy él a rendszer. Napközben nem nyüstöljük az éles rendszert. Én próbálkozok, hogy nyerjek egy kis erőforrást, mert amikor átvettem, akkor borzasztóan rosszul megírt szkriptek futottak ütemezetten

A következő kérdés lehetne, hogy a változásokat azonosítsuk. A rendszer olyan, hogy frissít több mezőbe szinte folyamatosan. Bár jogos, hogy azzal tudnánk nyerni, de a régi adatok beazonosítása, törlése, majd áttöltése lehet időigényesebb lenne.

Mess with the best / Die like the rest

Nem léteznek már eleve elosztott működésre képes megoldások?

Ami hirtelen eszembe jut, egy mongo is könnyedén szét tudja szórni az új adatot a cluster összes node-ján. Real time. A relációs DB-k erre nem képesek? Vagy olyan a felhasználási mód, ami mellett ez a megoldás nem jó ötlet?

Nem saját termékről van szó, hanem egy dobozos termékről, ami kötöttségekkel jár. Ezért az SQL server is. Rendelkezésre áll a SAS is, de arra átállni (backup esetén) meg idő lenne, amire persze nem szánnak időt. Rengeteg idő lenne a meglévő jobokat átírni

Én sok kis lépéssel próbálok javítani. Igazából szorgalmiként, mert mellette ott vannak a feladataim is :/

Mess with the best / Die like the rest

Ha jól értem, itt kőkemény gazdaságossági kérdések is bejátszanak.

Nektek kell eldönteni, hogy mire akartok költeni:
- újabb, erősebb vas
- toldozzátok-foltozzátok a régi kódot, hátha jobban fut az elégtelen vason

Írtad, hogy van DBAtok.

Nem az ő dolga lett volna eddig kielemezni a rendszer gyenge pontjait, és azon optimalizálni?
Akár úgy, hogy megnézi, mi fut túl lassan, és a végrehajtási terv alapján kitalálja, milyen indexszel vagy hintekkel lehetne jobban futtatni ugyanazt, vagy akár úgy, hogy nyakára lép a trehány fejlesztőknek, hogy gondolkozzanak, mielőtt telibejoinolnak két sokmilliós táblát.

Vagy azon is el lehet gondolkozni, hogy valami mentén partícionáljátok a táblákat.
Mittudomén, van egy folyamatod, aminek van egy azonosítója, akkor célszerű lehet az összes a folyamatban használt táblát a folyamat azonosító mentén partícionálni, és az összes joinba betenni a partíciókulcsot, így mindig csak az aktuális partíció pártíz-ezer során dolgozik a DB, nem az egészre megy a full table scan...

[szerk:]Ja, hogy dobozos? Akkor a beszállítót kell rugdosni, ha még garis a termék, de sejtésem szerint már fizetős a support
Pénz meg szokás szerint nincs.

Én sok kis lépéssel próbálok javítani. Igazából szorgalmiként, mert mellette ott vannak a feladataim is :/

Sajnos volt ilyen munkahelyem.

Amikor sikerült sok hónap munkával eloltanom egy évek óta lángoló tüzet, amit az egyik vezető fejlesztő nemtörődömsége okozott, akkor még vállveregetést sem kaptam érte, nem hogy fizuemelést.
Aztán még én voltam a szemét, amikor leléptem onnan...

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

A rendszer egy dobozos termék. Az adatbázisa is adott. Azon változtatni nem tudunk. Ezért a második opció az életképes. Egy 2008->2012 frissítésért is kuncsorogni kellett De így is lassan 10 éves lesz az új szoftver is. (Multikulti probléma.)

A DBA-nk optimalizálásba próbál segíteni, de mivel nem csak ezen dolgozik, így elég kevés ideje jut az ilyen dolgokra. Úgymond ránk bízza, hogy milyen kódot írunk. Ha több millió sor törlését indítjuk el vagy deadlock-ba botlunk, akkor természetesen jön és segít. De nem fér bele az idejébe, hogy monitorozza a tevékenységeinket.

Elvileg mi is meg tudjuk nézni a query plan-t és tudunk eszközölni javításokat. (De a felhasználók közül csak én vagyok olyan beteges, akinek számít a futási idő. Többieknek csak az számít, hogy lefusson.) Mondjuk meg szoktam osztani praktikákat, de onnan az ő felelősségük, hogy alkalmazzák-e.

A partícionáláson én is gondolkodok, mert van jó pár gyakran használt nagy táblánk, amin segítene. Csak elmagyarázni a többi felhasználónak, hogy mit hogyan.... IF vagy egy WHILE ciklusnál is teljes sötétség. Vagy, ha kell, inkább kézzel töltenek be 100 külső forrást, semmint ciklussal BULK INSERT-tel.

(Desszert: Egyik korábbi munkahelyemen meg VIEW-kat kezdtük el visszafordítani, hogy miből is épül és a 13. szint után feladtuk. VIEW-ra VIEW-t, majd arra VIEW-t építeni...Sok a szakbarbár a piacon, de persze ők sírnak a legjobban a pénzért.).

Bocsi a hosszért... Megyek eszek sütit. Nem panaszkodom. A replikációt biztos megbeszélem az DBA-val és a partícionálás nagyon terítéken van, mert sokat nyernénk vele.

Mess with the best / Die like the rest

Szevasztok
segítséget kérek, egy excel táblában gyógyszerkészítmények összetételét mig egy másik táblában a készitmények tulajdonságait leiró adatokat rögzitem. A tulajdonsághalmaz a gyógyszertipustól (baletta, kenőcs, kúp, szirup stb, függően változik azaz annyi tulajdonságtábla van ahány gyógyszertípus. Kérdés: milyen kapcsolatokat kell a táblák között kiépiteni illetve milyen SQL lekérdezéssel lehetne a táblákból a legegyszerűbb módon kiolvasni az információkat.

Sőt igaziból on-the-fly kellene replikálni, az a vicc, hogy az ugyan folyamatosan dolgoztatja a két szervert, viszont folyamatosan alacsony terheléssel.
Ezek a napi 1 megoldások viszont ugyan az éles szerveren kb. semekkora plusz terheléssel nem járnak (nem mintha az on-the-fly replika komoly terheléssel járna), viszont a teszt szerver arra az időre full használhatatlan.

Én kérek elnézést!

Dehogynem MS SQL-nél a replikálás pont erre való. Ultra gáz, hogy nem a DBA-juk, hanem egy akárki foglalkozik ilyen problémákkal.

Én kérek elnézést!

Egy 2008->2012 frissítésért is kuncsorogni kellett

Mielőtt Móricka azt képzelné, hogy régi DBn backup, aztán új szerveren restore, és máris megy minden, mint a karikacsapás, ennél nagyobbat nem is tévedhetne.

Annó egyik ügyfelünk nagyon nyüstölt minket az SQL Server 2000 miatt, hogy 2011-ben nem kéne már használni, aztán új DB szerver telepítésekor upgradeltette a rendszerét 2008R2-re.

Akkor a DBAink vagy egy fél hónapot reszelhették a régi kódot, hogy normálisan működjön a hárommal újabb DB verzióval, mivel felülről kompatibilitás ide vagy oda, az új DB motor sokmindent másképp optimalizált/futtatott, mint a régi.
Úgyhogy lehetett végignyálazni az indexeket, hinteket, meg utánaolvasni a 2008R2 újításainak, mivel a DBAnk főleg 2000-hez értett, meg kisebb részben 2005-höz.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Szia,

ha jól értem lesz két tábla. A kettő között a kapcsolatot a "gyógyszerkészítmény" fogja adni.
Egyik táblában az összetételek lesznek. Feltételezem soronként. Kicsit furcsa lenne olyan struktúra, hogy összetétel1, összetétel2, összetétel3,.... .
Másik táblában a tulajdonságok lesznek. Feltételezem itt is soronként lesznek felsorolva a hatások.

Ha a számomra "furcsa" megoldás van, akkor simán JOIN-nal összeköthetőek. Ugyanaz, mint a VLOOKUP az Excelben

A másik megoldás esetén simán mellé tenni, LEFT JOIN-nal nem érdemes, mert összes lehetséges párosítást adná vissza, ami biztos nem jó. PIVOT kicsit macera kezdőként.
Én személy szerint soronként tárolnám mindkét táblát. Az összetevőket és a tulajdonságokat is katalogizálnám. Azaz bevezetnék egy táblát, amiben egyes adatok kapnának egy azonosítót és a két táblában csak az azonosítókat kellene eltárolni. Később lehet meghálálja a rendszer és a tárhely. Például a penicilin szót eltárolni 9 karakter, de ha ez a 17-es kódú összetevő, akkor ez egy sokkal kisebb helyet igénylő adat.

Példa:
1-es azonosítójú gyógyszerkészítmény esetén

Első tábla
1 - összetevő: por
1 - összetevő: víz
1 - összetevő: penicilin

Másik tábla:
1 - tulajdonság: Fejfájás
1 - tulajdonság: Hányinger

Ha ezt kötöd össze, akkor ilyet kapnál:
1 - összetevő: por - tulajdonság: Fejfájás
1 - összetevő: víz - tulajdonság: Fejfájás
1 - összetevő: penicilin - tulajdonság: Fejfájás
1 - összetevő: por - tulajdonság: Hányinger
1 - összetevő: víz - tulajdonság: Hányinger
1 - összetevő: penicilin - tulajdonság: Hányinger

Na ez jó hosszú lett. Jó lenne ismerni a kiindulási alapot. Akár fake adatokkal összedobsz egyet a Google Drive-on, talán könnyebb lenne a megoldást megtalálni.

Mess with the best / Die like the rest

Én a DBA-ra nem haragszok, mert lehet rá számítani, csak sajnos más feladatokat is ellát. (Munkaszervezésbeli hiba az IT részlegen (szerintem).)

Én egy kicsit IT vénával megáldottüzleti elemző vagyok. Nem csak megírom a SELECT-et, hanem a teljesítményre és az olvashatóságra is igyekszek figyelni. De amúgy értem amire utalsz.

@nyunyu (4497): Elvileg a 2008->2012 átállás már jóvá lett hagyva és jönne az UAT, de se neki nincs erre ideje, se nálunk, mert persze ez nem fontos a fejeseknek. Tesztelés nélkül biztos nem engedném. Az nagyon amatőr lenne. A jelenlegi helyzetben meg a VPN döcög. Amúgyis nehezebben halad a munka

Mess with the best / Die like the rest