- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Kormányok / autós szimulátorok topicja
- E-book olvasók
- Vezeték nélküli fülhallgatók
- Apple notebookok
- OLED TV topic
- Milyen processzort vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- TCL LCD és LED TV-k
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
ph A szerverpiacra szánt Turin platform, illetve a mobil szintre nevező Strix Point érhető el a főbb partnerek számára.
-
Az üzleti chatbot lehet az új fejőstehén
it Üzleti chatbotot indított az Anthropic, azt reméli, hogy sok pénz folyik majd be a cégektől.
Új hozzászólás Aktív témák
-
nyunyu
félisten
Adott egy kulfoldi fejlesztesu programcsomag, ami InterBase adatbazist hasznal.
Problemam az, hogy akarhanyszor adatbazis hiba van, es kikuldom a gdb fajlt a fejlesztoknek, akkor mindig kulfoldi nyelvu adatokkal kapom vissza a javitott adatbazist.Kaptam a fejlesztoktol egy nagyonhosszu SQL fajlt, ami tele van UPDATE-ekkel, es vegignyalazza az adatbazist, mindent atirva angolra.
Ezt megelozendo le szeretnem menteni a mostani _magyar_ adatbazisom tartalmat, hogy ha gond van, akkor egy SQL szkript lefuttatasaval visszairna az adatokat magyarra, mert nincs kedvem fel napokat ezzel az adatbazis kezi buheralasaval szorakozni.IBExperttel kinlodok egy jo ideje, extract metadata opcioja priman mukodik, csak eppen ilyen formaban hozza letre az SQL fajlt:
INSERT INTO COUNTRY (ID, CODE, NAME, CLASSIFIER, CATEGORY, ENABLED, CODE2, INFO, PARAMSTR) VALUES (36, 'AO', 'ANGOLA', '024', 8, 1, 'AO', '', '');Ha ezt megetetem az InterBase SQL futtatojaval, allandoan hibat dob, hiszen mar letezik ilyen sor.
Nekem valami ilyesmi formaban kellenenek:
UPDATE COUNTRY SET
CODE = 'AO',
NAME = 'ANGOLA',
CLASSIFIER = '024',
CATEGORY = 2,
ENABLED = 1
WHERE (ID = 36);Letezik erre valami _jo_ program, ami ilyen UPDATE queryket general a meglevo tablakbol?
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Egyszerubb volt a problema, mint hittem.
Kulfoldi kollegak felvilagositottak, hogy amikor IBExperttel megnyitom a lementendo tablat, akkor a toolbarban megjelenik egy "export data" ikon, arra kattintva allithato, hogy "UPDATE statement", vagy "INSERT statement" formaban mentse el oket...
(Gondoltam, hogy van valami ilyesmi opcio, csak en a menusort nyalaztam at, ott meg csak az Export Metadata volt, ami nem igy mukodik.)
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Adott egy SQL Server 2008R2 alatt letrehozott adatbazis/tabla, amit at kene varazsolni SQL Server 2005 ala, mert a celgepen csak az van.
Hogyan lehet atvinni?
Probaltam mar a sajat gepemrol SQL Management Studio 2008R2-vel betallozni a 2005-os szervert, kivagott, hogy a szerver nem tamogatja a protokoll verziot, akar TCP/IP-re, akar named pipes-re allitottam a kapcsolatot.
Masik gepen levo SQL Management Studio 2005 persze "kiszolgalo nem talalhato"-val vag ki, hiszen nem tamogatja az ujabb SQL-t.
Multkor probaltam lebackupolni az adatbazist, hogy melohelyi SQL 2008-on visszaallitsam, annak meg az volt a baja, hogy ott sima 2008 van, nem R2.
CSV-be export, aztan import nem jatszik, mert 3 ora alatt sem sikerult ugy beallitanom az importot, hogy ne dobjon "nem lehet konvertalni az adatot" jellegu hibat
BTW, lehet ezzel a nyuves SQL Management Studio-val olyat csinalni, hogy a tabla osszes adatabol general egy futtathato SQL fajlt, ami egyesevel beinzertalja egy tablaba az adatokat?
InterBase/Firebird-hoz valo IBExpert progival lehetett ilyet csinalni...
SQL Management Studioban adatbazison jobb klikk/Script As../Insert INTO az csak a tabla fejlecet irja meg, adatokat persze nem teszi bele
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
En lenni
Most jottem ra, hogy a gepemre felrakott Visual Studio 2008 feltett egy SQL Express 2005-ot, arra viszont siman be tudok jelentkezni az SQL Management Studio 2008R2-mmel, at is importaltam az adatot, SQLExpress 2005 alatt backup, celgepre atmasol, SQL2005 alatt siman restore.
Feleslegesen szivtam az adat attoltessel 6-7 orat
Mondjuk azt meg mindig rejtely, hogy a sajat gepen futo 9.0.4053-as SQLExpress 2005-re miert tud rakapcsolodni, mig a masik gepen futo 9.0.4053-as SQL 2005-re meg miert nem.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Backup/Options ablakon nem latok mas SQL-re mentesi lehetoseget.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Egy adattarhazas cuccban lattam ilyen furcsa queryket:
update tabla1
set valtozo=tabla2.valtozo2
where tabla1.id=tabla2.id;update tabla1, tabla2, tabla3
set valtozo=tabla3.valtozo
where tabla1.id=tabla2.id and tabla2.valami=tabla3.valami;Ez mennyire bevett szintaxis?
SQL 2008R2-nek termeszetesen egyik implicit join sem tetszik.Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Egyetemen azt tanitottak, hogy ma mar ekvivalens ez a ket query:
select *
from tabla t1
join tabla2 t2 on t1.id=t2.id
where t2.nev='valami';select *
from tabla1 t1, tabla2 t2
where t2.nev='valami' and t1.id=t2.id;Mind az Oracle, mind az MS SQL automatikusan atalakitja az elso szintaxist a masodik formara, es ugy optimalizalja.
Regen maskepp fordult le a ketto, jobban tudtak optimalizalni, ha vesszovel soroltad fel a tablakat.Na, de updatetelendo tablahoz joinolni??? Az nekem uj.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Adott egy tabla, amiben csomopont adatai, meg celtol valo tavolsag ertekek vannak.
Problema az, hogy egy csomopont a celtol tobb kulonbozo tavolsagra is lehet, attol fuggoen, hogy a grafot bejaro algoritmus eppen milyen uton jutott oda. (A->B->C eseten 2, A->C eseten 1...)Ezt kene valahogy ugy megupdatelni, hogy x,y parosnak mindenhol a maximalis erteke legyen, mert a graf rajzolo progi hulyet kap tole, ha egy csomopontot tobb kulonbozo tavolsaggal is probalom definialni.
Hogy lehet ezt szepen megirni?
Valami ilyesmi kene:
UPDATE a
SET hier_lvl=b.hier_lvl
FROM valami a,
(SELECT x, y, MAX(hier_lvl)
FROM valami
GROUP BY x, y) b
WHERE a.x=b.x AND a.y=b.yCsak kevesbe adattarhazas dialektikaval, hogy az SQL Server is megertse.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Petya25 #1920 üzenetére
Mi a datum formatuma?
Pl. ha a win '2013-08-12'-ot ad vissza, az nem fog betalalni a '2013.08'-hoz.
Lehet, hogy egyszerubb lenne a year, month fuggvenyekkel szetdarabolni+a lekerdezesben ujra osszerakni a datumot, es akkor nem okozna gondot az eltero formatum.
SELECT * FROM honapok WHERE ho = " + "'" + YEAR(CAST(vizsgaltnap AS DATETIME)) + "." + MONTH(CAST(vizsgaltnap AS DATETIME)) + "'" + " and lezarva = 1
Legalabbis az SQL Server igy castolva siman megeszi a '2013-08-12', '2013.08.12', '08-12-13' formatumot is.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Majdnem.
year, month eredmenyet vissza kell castolni varcharra, kulonben nem hajlando osszefuzni a stringekkel.
Illetve az is problema, hogy az egyjegyu honapoknal nem teszi ki a nullat a honap ele, igy az osszefuzott string '2013.8' lesz.Igy vagy kezzel atirod a tablaban az ertekeket ilyen formara, vagy lehetne bonyolitani a lekerdezest CASE-sel, de szerintem egyszerubb kettebontani a ho oszlopot ev+ho-ra, aztan utana egy szimpla query is megteszi:
SELECT * FROM honapok WHERE ev = YEAR(CAST(vizsgaltnap AS DATETIME)) AND ho = MONTH(CAST(vizsgaltnap AS DATETIME)) AND lezarva = 1Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Petya25 #1924 üzenetére
Debugnal megnezted, mi a lekerdezes string aktualis erteke?
Ezt kezzel feladva Accessnek mi az eredmeny?Esetleg atirni a *-ot COUNT(*)-ra, ugy mindig lesz eredmenye a querynek, talalatok szamatol fuggoen nullanal nagyobb vagy 0.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz orbanka #1935 üzenetére
Gondolom kb. akkora lehet a kulonbseg az elso es a masodik verzio kotott, mint MS platformon a Linq es az SqlCommand osztaly hasznalata kozott.
Linq baromi kenyelmes, mert definialod az adatkotest, aztan a tablak frissiteset, betolteset, stb. a hatterben magatol intezi a .NET keretrendszer, nem neked kell megirni, hogy ha modositanak egy mezot a griden, akkor mit hova updateeljen.
Viszont ez durvan 200x lassabb kodot general, mint ha megirnad SQLben, es feladnad rendes querykent, ahol viszont nem biztos, hogy minden esetre gondoltal, es kimaradhat valami...
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Fundiego #3550 üzenetére
Önmagával left outer joinnal kiszűrni a "duplikációkat"?
Valami ilyesmi Oracleben:
select t1.*
from tabla t1, tabla t2
where t1.c=t2.b (+)
and t2.b is null;Vagy szabványos szintaxissal:
select t1.*
from tabla t1
left join tabla t2
on t1.c=t2.b
where t2.b is null;[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz velizare #3596 üzenetére
Nincs erre valami parancs, amit minden lefuttatott script elejére be tudsz szúrni, hogy UTF8 kódolást használjon?
Mi Oracle DBAink is szoktak szívni azzal, hogy mentenek egy scriptet PL/SQL Developerből, aztán a prod környezet üzemeltetéséért felelős "kolléga" SQL Developerből futtatva mindig telibevágta vele az éles adatokat.
Azóta minden neki küldött script úgy kezdődik, hogy
ALTER SESSION SET NLS_LANGUAGE=...Aztán jönnek csak az ékezetes stringeket tartalmazó INSERTek.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Fundiego #3600 üzenetére
Ablakozó függvénnyel beszámozod a pilótánkénti helyezéseket, majd leválogatod, melyik lett az első, második, harmadik?
Oracle alatt valami ilyesmi lenne:
with eredmeny
as (select id,
ev,
vegeredmeny,
pilota,
pont,
row_number() over (partition by ev, pilota order by vegeredmeny, id) eredmeny
from futam)
SELECT e.pilota,
SUM( e.pont ),
e1.vegeredmeny er1,
e2.vegeredmeny er2,
e3.vegeredmeny er3,
e3.vegeredmeny er4
FROM eredmeny e
join eredmeny e1
on e1.ev=e.ev
and e1.pilota=e.pilota
and e1.eredmeny=1
join eredmeny e2
on e2.ev=e.ev
and e2.pilota=e.pilota
and e2.eredmeny=2
join eredmeny e3
on e3.ev=e.ev
and e3.pilota=e.pilota
and e3.eredmeny=3
join eredmeny e4
on e4.ev=e.ev
and e4.pilota=e.pilota
and e4.eredmeny=4
WHERE e.ev = 2017
GROUP BY e.pilota,
e1.vegeredmeny,
e2.vegeredmeny,
e3.vegeredmeny,
e4.vegeredmeny
ORDER BY SUM( e.pont ) DESC;[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bandi0000 #3612 üzenetére
N:M reláció:
Jól látod, foglalásnak külön tábla kell 4 oszloppal:
- foglalt termék idegen kulcsa
- foglaló vevő idegen kulcsa
- foglalás ideje
- foglalás áraMajd az itt tárolt külső kulcsokkal joinolod össze a foglalót a foglalt termékkel.
[szerk:]Céges feladat? Ez inkább egy állásinterjúhoz szakmai beugrónak tűnik, amit fél délután össze lehet rakni.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bandi0000 #3614 üzenetére
Úgy több-több a kapcsolat, hogy egy vásárló több eladótól is vehet (az mindegy, hogy mikor), de egy eladó termékeit is több vevő veheti.
Labor házidra ugyanez igaz, egy ember több fodrászhoz is foglalhat időpontot, de egy fodrásznak is több vendége van egy nap, és ezek egymástól függetlenek.
Minden egyes tranzakció egy új rekord lesz a foglalásos táblában.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Ránézésre az lesz a baja, hogy nem stringként van beillesztve a dinamikus querybe a táblanév.
Körbe kéne rakni aposztróffal, valahogy így:
SELECT '''+dbs.name+''' AS Tenant[szerk:]T-SQLben dupla aposztróffal kell escapelni az aposztrófot, nem \' mint más nyelveken.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz bambano #3645 üzenetére
Ilyesmi feladatba már sikerült belefutnom melóhelyen.
Ottani kódom erősen leegyszerűsítve.DB adminjaink persze nem szoktak szeretni érte, amikor több millió soros táblákból kell kibogarásznom pár tízezer hasznos rekordot, majd azokat intervallumokba rendezni...
Query plant kielemezve mindenféle Cartesian join kerülendő szakszavakkal dobálózva próbálják levenni a rontást a DB performanciáról.Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Iginotus #3658 üzenetére
valami ilyesmi:
declare i number;
begin
for i in 1 .. 9 loop
update ...
where row_id=i
end loop;
end;Kevésbé procedurálisan gondolkozva persze meg lehet írni egy updatetel is, mivel van sorfolytonos IDd a táblán, amihez lehet row_number()-rel joinolni:
update sds.forge upd
set code_neu=
(select a.orgeh_code from
(select oe.*, row_number() rn from sds.oe
order by dbms_random.value) a
where a.rn=upd.row_id);[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Iginotus #3664 üzenetére
Ablakozó függvényt lefelejtettem:
update sds.forge upd
set code_neu=
(select a.orgeh_code from
(select oe.*, row_number() over (order by dbms_random.value) rn
from sds.oe) a
where a.rn=upd.row_id);vagy valami ilyesmi.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
-
nyunyu
félisten
PHPből hívott tákolt eljárásnak átadod paraméterként a módosítandó értékeken kívül az elkövetőt is, aztán nem egy insert lesz benne, hanem egy másiodikkal a napló táblába szúrod az elkövetőt, tetthelyet, időbélyeget?
Trigger nagyon jó arra, hogy kikényszerítsd az adatbázis konzisztenciát, de annak jelentős teljesítményvesztés az ára.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz galocza #3727 üzenetére
Ez elég nehezen távgyógyítható témakör, és a sarki pistike nem biztos, hogy saját kútfőből meg tudja oldani okosba'
Ha meg a kasszarendszert hivatalosan supportáló brigád cserélte sok pénzért a komplett gépet ahelyett, hogy megvizsgálta volna, hogy
1) hálózati kapcsolat elég stabil-e kábelteszterrel, és ha szükséges, akkor kábel újrakrimpelés RÁ VALÓ dugóval */komplett kábel csere, ha a régi menthetetlen
2) gépen jól van-e beállítva a DB connection string (pl. servert keresi-e a helyben futó Firebird példány helyett)
Akkor toll a fülükbe.*: Tömör fali kábel vs egyenes késes UTP csatiról tudnék órákat mesélni...
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
-
nyunyu
félisten
Between azért is szívás lehet, mert ha varcharban tárolt értékeket próbálsz hasonlítani, akkor az implicit típuskonverzió számmá, aztán az csúnyán el tud szállni, ha benézel egy NULLt vagy egy nem jól/jókor szűrt táblát.
Pl. hiába teszel a between elé egy upper(x)=lower(x)-et plusz egy is not null-t, hogy a nem számokat kiszűrd, mert nem biztos, hogy mindig ugyanolyan sorrendben fog szűrni az adatbázis...
Oracle például szereti párhuzamosan kiértékelni a join feltételeket: mindegyik lefut minden sorra, aztán a részeredményekből legózza össze a join eredményét.(Telefonszámokat kellett sorfolytonos tartományokba rendeznem, ahol a telefonszám mezőben egyéb azonosítók is lehettek a nem telefon jellegű rekordokon...
Lexebb a '#47543' érték volt, ami a varchar(10)-ból kilógó hosszúságú telefonszámot tároló másik táblára mutató pointer akart lenni.
Ja, átment az upper(x)=lower(x) teszten.)[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz GreenIT #3879 üzenetére
Valamelyik régebbi, XPre még feltelepíthető SQL Server Express?
Ahogy nézem a 2008 R2 SP2 még felmenne, 2012 már nem.Azokban lévő SQL Server Management Studio GUIja nem sokban különbözött a Visual Studiotól.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz BuktaSzaki #4422 üzenetére
SELECT DISTINCT s.szerzodesID,
CASE
WHEN s1.tetel IS NOT NULL AND s2.tetel IS NOT NULL THEN 'Mindkettő megvan'
WHEN s1.tetel IS NOT NULL AND s2.tetel IS NULL THEN 'Csak az első'
WHEN s1.tetel IS NULL AND s2.tetel IS NOT NULL THEN 'Csak a második'
ELSE 'Egyik se'
END tetelek
FROM szerzodesek s
LEFT JOIN szerzodesek s1
ON s1.szerzodesID = s.szerzodesID
AND s1.tetel = 'Tetel1'
LEFT JOIN szerzodesek s2
ON s2.szerzodesID = s.szerzodesID
AND s2.tetel = 'Tetel2'
WHERE s.datum>SYSDATE-30
ORDER BY s.szerzodesID;Főnököm mondjuk megölne a distinct miatt, meg nem árt egy index a szerzodesID mezőre, ami mentén joinolod önmagával a táblát, különben elég elborult végrehajtási terve lenne.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Ha az a cél, hogy enumokat tárolj, akkor egy szótártábla elég, amiben van enum_neve, sorszám, érték.
(Aztán utána lehet hitvitákat folytatni, hogy nullától vagy egytől indexeljünk, lásd java vs sql)Ha viszont Hibernateet akarsz használni DB kezelésre, akkor jól gondold meg, hogy mire vállalkozol, mert az arra tökéletesen alkalmatlan.
Előző projekten alapvetően Oracle DBben fejlesztettünk egy üzleti alkalmazást, afölé lett Javaban írt frontend-backend téve, aztán az eredeti elképzelés az volt, hogy a Hibernate közvetíti az DBben lévő adatokat a Java GUI felé.
Aha, iszonyúan erőforráspazarló, nem gyors, de legalább az összes adatműveletnél lockolja az összes érintett táblát, tábla szinten.Gyakorlatban totálisan alkalmatlannak bizonyult többfelhasználós célokra, mert folyamatosan homokórázott a rendszer a Hibernate hülyeségei miatt lockolt táblák miatt.
Végül az össze 3 táblából összejoinolok egy táblázatot kérdésre az lett a válasz, hogy a GUI meghív egy tárolt eljárást, ami elvégzi a joint, és az eredményt visszaadja egy kurzorban, aztán annak a tartalmát húzták be a kliens oldalon tovább szűrhető gridbe.
Vagy natív query.A másik nagy kedvencem a késleltetett írás témája.
Felhasználó képernyőn kitölt egy táblázatot, amit egy az egyben a Hibernate ment egy DB táblába.
Elmélet az, hogy a táblázat soráról elvéve a fókuszt azonnal menti a módosult sort a DBbe.
Gyakorlatban? Ha a felhasználó rábökött a Tovább gombra, ami meghívott valami tároltat, ami a frissen töltött táblát használta, akkor az esetek 20%-ában nem volt elmentve az utoljára szerkesztett sor, és a DBben implementált logika emiatt hülyeséget csinált.
Én meg nyomozhattam, hogy mi a francért van jó adat a forrástáblában, az adattranszformáció végén meg rossz. (Hibernate végül mégiscsak elmentette, miután a DB már felhasználta a rossz adatot...)
Végeredmény? Javas kollégákkal veszekedtem pár napot, hogy a DB tárolt hívása előtt MENTSÉK el a táblát.Ez vajon megoldotta a problémát?
A fenéket, méréseim szerint még mindig 3% adathibát okoz, hogy a SaveAndFlush() sem ment azonnal.
Utolsó ötletük a javas kollégáknak a probléma megoldására a Thread.Sleep(500) beiktatása volt a SlaveAndFlush() és a DB tárolt hívás közé...
Mivel az ilyen hókuszpókuszokban nem bízom, inkább beraktam egy összehasonlítást a transzformáció végére, hogy ha inkonzisztenciát lát, azonnal fusson újra az időközben mentett adatokra.Harmadik agybaj meg az volt, hogy a Hibernate konkrétan lebénul attól, ha olyan táblába kell sorokat beszúrnia, ahol a tábla egyedi kulcsát képező szekvencia egyesével lépked. (ami ugye a DB default beállítás...)
Javas kollégák magyaráztak valami marhaságot arról, hogy a Hibernate húszasával becacheli előre a leendő ID értékeket, így a szekvencia lépésközét ennél nagyobbra kell állítani, hogy ne akadjon össze a DBvel egy-egy insertkor.Szóval csak óvatosan a Hibernatetel, mert attól erősen csökken a savassága a DBnek.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
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?
-
nyunyu
félisten
válasz kw3v865 #4459 üzenetére
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?
-
nyunyu
félisten
válasz bambano #4461 üzenetére
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?
-
nyunyu
félisten
válasz bambano #4472 üzenetére
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?
-
nyunyu
félisten
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?
-
nyunyu
félisten
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?
-
nyunyu
félisten
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?
-
nyunyu
félisten
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?
-
nyunyu
félisten
válasz martonx #4538 üzenetére
Egyébként MySql-nek (meg amúgy bármelyik SQL-nek) tök jól lehet paraméterezni a memória foglalását.
A teljesítmény rovására.
Nézz meg egy ingyenes, egy procimag+1GB RAMra limitált MS SQL licenszet, meg a rendes verzióját.
DB tipikusan olyan alkalmazási terület, ahol a több RAM mindig jobb.
Persze ha van három táblád, 10-10 sorral, akkor az 1GB is elég lehet, de párezer soros táblák joinolgatásánál már észreveszed a különbséget.
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Jim Tonic #4545 üzenetére
Ezeket egy selectben nem tudod összeszedni, mivel az oszlopfüggvények egymástól függetlenül értékelődnek ki.
Tehát nem max(valid_from)-hoz tartozó min(valid_to) értéket kapod vissza, hanem a globálisat.Maximum azt tudod tenni, hogy egy belső selectben leválogatod a max(valid_from)-okat minden termékhez, majd az a köré írt másik selectben kiveszed a min(valid_to)-t.
Valahogy így:
select product,
price
from products p
join (select
p1.product,
a.max_valid_from,
min(nvl(p1.valid_to, to_date('9999-12-31'))) min_valid_to
from products p1
join (select p2.product,
max(nvl(p2.valid_from, to_date('0000-01-01'))) max_valid_to
from products p2
group by p2.product) a
on a.product = p1.product
and a.max_valid_from = p1.valid_from
group by p1.product, a.max_valid_from) b
on b.product = p.product
and b.max_valid_from = nvl(p.valid_from, to_date('0000-01-01'))
and b.min_valid_to = nvl(p.valid_to, to_date('9999-12-31'));Oszlopfüggvények alapból figyelmen kívül hagyják a nullokat!
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Jim Tonic #4548 üzenetére
Ja tényleg, ablakozó függvényekkel lehet, hogy egyszerűbb, mivel ott összetett rendezést is tudsz alkalmazni:
select
p.product,
p.price
from products p
join (select
p1.product,
nvl(p2.valid_from, to_date('0000-01-01')) valid_from,
nvl(p1.valid_to, to_date('9999-12-31')) valid_to,
row_number() over (partition by p1.product
order by nvl(p2.valid_from, to_date('0000-01-01')) desc,
nvl(p1.valid_to, to_date('9999-12-31')) asc) rn
from products p1) b
on b.product = p.product
and b.valid_from = nvl(p.valid_from, to_date('0000-01-01'))
and b.valid_to = nvl(p.valid_to, to_date('9999-12-31'))
and b.rn = 1;Ezzel sorszámozod az egy termék rekordjait kezdő dátum szerint csökkenő és azon belül érvényességi dátum szerint növekvő sorrendben, majd veszed a legelső rekordot minden termékhez.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Új hozzászólás Aktív témák
- Eredeti játékok OFF topik
- Fotók, videók mobillal
- Suzuki topik
- Kerékpárosok, bringások ide!
- Politika
- Luck Dragon: Asszociációs játék. :)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kormányok / autós szimulátorok topicja
- Elektromos rásegítésű kerékpárok
- E-book olvasók
- További aktív témák...