- iPhone topik
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Mobil flották
- India felől közelít egy 7550 mAh-s Redmi
- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
Új hozzászólás Aktív témák
-
#4342
Apollo17hu
őstag
bpx
#4341
Apollo17hu
őstag
Guglizás közben olvastam a container és a pluggable database-ről, de - ahogy írod is - fogalmam sem volt, hogy lehetne normálisan beállítani.
Nincs Linux ismeretem. Akkor azt mondod, hogyha XE helyett EE-t rakom fel, sokkal egyszerűbben hozzáférek majd a sample schema-khoz? Éjjel már ott tartottam, hogy a zippelt HR-sémát githubról töltöm le, csak az importálásnál megint falakba ütköztem.
-
bambano
titán
"Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.": ez így nyilván csak a példa kedvéért került elő.
a termék árát akkor kell kivenni a vásárlásból, ha az minden vásárlásnál ugyanaz. tehát ha a bukóhullámú homálytizedelő mindig 3 gombba kerül, akkor a termék törzsben az ár helye, ha vásárlásonként változik az ára, akkor meg a vásárlás táblában. ilyenkor úgyis az lesz a vége a történetnek, hogy lesz ilyen-olyan vevő, más és más árengedménnyel, stb, és az ár marad a vásárlás táblában.
-
amdni
aktív tag
mysql> SELECT @@GLOBAL.foreign_key_checks, @@SESSION.foreign_key_checks;
+-----------------------------+------------------------------+
| @@GLOBAL.foreign_key_checks | @@SESSION.foreign_key_checks |
+-----------------------------+------------------------------+
| 1 | 1 |
+-----------------------------+------------------------------+
1 row in set (0.01 sec)Úgy látom hogy ez jó, de nálam mégsem jó valami...
-
-
igaz. engem általában kielégít az ilyetén használata, de elfogadom, végülis nem erre való, igazad van.
megnéztem, hogy mi mit használunk ilyenre, és ahol van, ott egy szekvencia van rá felvéve, amit egy tábálra rakott before insert trigger pakol bele az új sorba. de gondolom ennél azért már szebb módszerek is vannak erre.
-
-
sztanozs
veterán
Nem volna egyszerűbb egy nested join?
SELECT t1.mezo_1
,t1.mezo_2
FROM (SELECT t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
INNER JOIN
(SELECT t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
ON t1.id = t2.id; -
#3445
Apollo17hu
őstag
bpx
#3443
Apollo17hu
őstag
PL/SQL Developer 9.x-ről álltunk át a napokban 12-es verzióra. Valószínűleg ez lehet a probléma forrása (talán az üzemeltetés nem hangolta tökéletesre az adatbázis szervert?).
Plant nem tudok mutatni, a lekérdezés egyébként kb. így néz ki:
SELECT t1.mezo_1
,t1.mezo_2
FROM (SELECT t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
,(SELECT t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
WHERE t1.id = t2.idEz futott korábban 1 másodpercig, most meg 5-10 perc között. t1 és t2 allekérdezés is 200-300 eredménysort ad vissza (mindkettő dimenziótábla), külön-külön 1 másodpercen belül most is lefutnak. Mindkét táblában az id egyedi, szám formátumú.
Az a vicces, hogyha t1 allekérdezésben találomra kikommentezek egy szűrőfeltételt (az eredménysorok száma 10-15%-kal nő), akkor az egész lekérdezés ismét 1 másodpercen belül fut.
Legalapabb hintekkel próbálkoztam (use_hash, use_nl stb.), de igazából nem tudom, mikor mit kell használni. Tapasztalatból csak annyi van meg, hogy nagyméretű ténytáblák kötésénél 90%-ban csökkenti a futási időt a use_hash hint.
Tudom, hogy ez még mindig kevés, és hogy jobban kellene specifikálni a problémát, de a hét végére valószínűleg kapok segítséget munkatársaktól, tehát mindenképp meg fog oldódni a probléma, csak azt hittem, vannak általánosan alkalmazható hintelések.
-
htcwanted
csendes tag
Például: table_B egy megosztott tábla amiben a userek tudnak frissíteni információt.
table_A mindennap frissül table_B alapján, és más helyeken van használva, reportok, nézetek, Front End.
Dinamikus frissítés sajnos nem lehetséges, a napi egyszeri automatikus szinkronizálás jelenleg teljesen kiszolgálja a különböző funkciókat. -
bambano
titán
ha már piszkos dolgokat művelünk
itt egy kezdemény postgresql-ben:select szo,s.a from worduniq,generate_series(1,char_length(szo)) as s(a);tmp=> select * from worduniq;
szo
-----------------------
123456123
123456123223453473456
229898012342
(3 rows)
szo | a
-----------------------+----
123456123 | 1
123456123 | 2
123456123 | 3
123456123 | 4
123456123 | 5
123456123 | 6
123456123 | 7
123456123 | 8
123456123 | 9egy substring, egy distinct select és az eredmény összepakolása van hátra. ezeket, egyszerűségük folytán, az olvasóra bízzuk
-
#30734848
törölt tag
Az előbb rosszul fogalmaztam, elnézést, csak már nem volt időm még egyszer szerkeszteni. Ez a számsor két mezőnek az összefűzéséből jön létre (Az számok egytől nyolcig információt jelölnek.). Ezért van szükség az ismétlődések kiszűrésére
Szóközzel lehet érthetőbb:
('1 2 3 4 1 2') -- > ('1 2 3 4')
Tehát az a kérdés, hogy mivel lehet a számok ismétlődéseit kiszűrni, hogy minden érték csak egyszer szerepeljen.
-
Louro
őstag
Szia,
powershell elindul. Régen még tanultam is. Megpróbálom elsőként abban megoldani.
Nem ragaszkodok a Windows saját ütemezőjéhez, de mivel nem vagyok admin, nem vagyok DBA, így korlátozottak a lehetőségeim. A DBMS Scheduler-ért küzdünk, de az nem 100%, hogy meglesz. Így a meglévő eszközökhöz nyúlnék.
-
Louro
őstag
Igazából az a feladat, hogy van egy tábla, amiben van x darab rekord. Ez folyamatosan változik. A rekordokat 3 részre kell megadott feltételek mentén bontani.
Az új táblában pedig
- 3 kategória alapján megszámolni mennyi rekord van az első táblában.
- majd mindegyikhez növekvő sorszámot társítani.Ezt most úgy csináltam meg - és lefutott - kivettem a 3 kategória darabszámát az első táblából. Majd 3 ciklussal mellé tettem a növekvő sorszámot.
SQL-lel még kategóriánként meg tudom számoltatni, hogy melyikhez mennyi tartozik, de a növekvő sorszámot már nem. Mondanám, hogy 3 temp tábla, de akkor extra táblákat kellene létrehozni.SQL ismeretem kicsit jobb, mint kezdő, de messze nem merész amatőr.
-
#2641
dellfanboy
őstag
bpx
#2635
dellfanboy
őstag
közbe gondolkoztam és rájöttem, hogy rosszul tettem fel a kérdést.
mert az első kérdésemmel azon id-kat találom meg akik 1.-jén (date from) aktívak 30.-áig (date to)
de én arra vagyok kiváncsi 1 hónapban hány új id lett/szünt meg
tehát kell képeznem egy februári halmazt és egy márciusit. e kettő különbsége adja meg az növekedést/csökkenést.tehát egy olyanre kellene szűrnöm első sorban hogy a date to cella üres(aktív) a date from pedig adott hónapban töltődött ki. és ha ez megvan, akkor nem is kellene a halmazokkal szórakoznom, hisz megvan az adott hónapban 'született' id-k halmaza. amit keresek.
tehát a date from feb1-feb28 között bármilyen dátum, a date to pedig üres
-
bambano
titán
persze, hogy nincs különbség, ha a limites átírásoddal pontosan azt a részt teszed tönkre, ami a lényegi különbség a két lekérdezés között.
próbáld ki ezt a két lekérdezést:
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASCés
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk where rownum<4 ORDER BY aru_egysegar DESC) aruk_kivonat
ORDER BY aruk_kivonat.aru_egysegar ASCez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
adjon valaki hitelt érdemlő bizonyítékot, hogy az a query, ahol a belső select 1 millió sort ad vissza, ugyanannyi idő alatt lefut és pontosan ugyanannyira optimális, mint az, ahol a belső select csak 3 sort ad vissza.
szerk: illetve futtasd le a subselecteket önmagában és nézd meg a találati halmaz nagyságát.
-
bambano
titán
általában a window funkcióknál nem fog, ez igaz, de én nem általában írtam, hanem a konkrét megoldásra.
"egy ilyen egyszerű példában nincs különbség.": ezt az állítást nem ártott volna bebizonyítani, ebben az esetben kiderül, hogy tévedés, és nem készül belőle hozzászólás.
1 millió rekordos teszt adatbázison jól láthatóan gyorsabb a sima subselectes.
test=> explain SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Sort (cost=109649.00..110482.34 rows=333333 width=36)
Sort Key: t.aru_egysegar
-> Subquery Scan t (cost=0.00..60836.36 rows=333333 width=36)
Filter: (t.sorrend < 4)
-> WindowAgg (cost=0.00..48336.36 rows=1000000 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(6 rows)test=> explain SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Sort (cost=0.15..0.16 rows=3 width=36)
Sort Key: aruk.aru_egysegar
-> Limit (cost=0.00..0.10 rows=3 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(4 rows)time psql -d test -c 'SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;'
real 0m0.639s
user 0m0.024s
sys 0m0.016stime psql -d test -c 'SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC'
real 0m0.032s
user 0m0.024s
sys 0m0.004sha kiveszem a subselecteket és azokat hajtom végre, akkor az első megoldás visszaadja az összes rekordot, a második meg csak hármat.
Fentiek alapján melyik lekérdezés a gyorsabb, optimalizáltabb???
"egy ilyen egyszerű példában nincs különbség.": 19.93750-szeres a különbség egymillió tesztrekordon. A teszt végére még volt üres ram a gépben, tehát nem az döntött, hogy az egyiket vinyóról futtatná, a másikat memóriából, minden teszt teljesen befért a ramba.
-
DopeBob
addikt
Van egy olyan lekérdezésem, aminél egy év és egy hónap a bekért adat, mondjuk cikkcsoportonként átlagot számol, ez egy oszlop. Ez mellé, ugyan azoknak a cikkcsoportoknak a következő hónapra tervezett adata is ott van, ennek az oszlopnak kéne egy normális nevet adni.
január február
alma 1 2
körte 3 4 stbsysdate-1 hónaptól indul és sysdate +3-ig tart, csak az elnevezésekkel szopok
-
PazsitZ
addikt
Szerintem messze nem az az olvashatóbb forma, plusz elméletileg a JOIN a szabvány táblakapcsoláshoz.
Mit, mihez, miért csatolsz, sokkal jobban látható a második példából, épp komplexebb lekérdezéseknél.
Ránézel a Join-ra mi mihez, a where feltétel ezután alap esetben nyilvánvaló nem is nagyon kell olvasgatni.De amúgy egyéni preferencia kérdése
. -
-
-
Jim-Y
veterán
Köszi, szerintem ez jó lesz
"nem a teljes hét kell?
mezo1 >= X-1. hét első napja AND mezo1 < X. hét első napja" de, igazad van, csak elírtam
köszönöm
megj: annyi kérdésem azért lenne, hogy a 5 DAY, illetve a -2 DAY az mára van optimalizálva ugye? Tehát ha holnap nézném, akkor már nem ugyanezt az eredményt adná igaz? Magyarán ki kell választanom, hogy melyik napra automatizálom az eljárást, és ezekben a sorokban ahhoz kell igazítanom az INTERVAL-t..
-
'Trunc' is not a recognized built-in function name.
Ilyenkor mi a helyzet?
Microsoft SQL Server Management Studio 10.50.4000.0
Microsoft Data Access Components (MDAC) 6.1.7601.17514
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.0.8112.16421
Microsoft .NET Framework 2.0.50727.5466
Operating System 6.1.7601 -
alratar
addikt
Akkor leírom, hogy miért is kellene ez.
Egy olyan adatbázist szeretnék csinálni, ahol futball játékosok neveit és adatait lehet felvinni.
És mivel, ugye a játékos állomány folyamatosan változik (eladják őket stb) így az id hosszúsága előbb-utóbb több tíz hosszúságú is lehet.
És ezt szettném kibekkélni! -
sztanozs
veterán
Bocs nem neked akartam válaszolni...
alratar: Primary ID-t nem lehet "egyszerűen" módosítani, mivel roncsolja az integritást. Ha fontos, hogy növekvő és folyamatos sorrend legyen, ikább érdemes egy generált mezőt használni (vagy egyszerűen kiiratásnál beszámozni a mezőket). AZ ID mezők nem erre valók, hanem hogy az adatkapcsolatokon keresztül az integritás (mi tartozik mihez) megmaradjon.
-
martonx
veterán
Azért a materialized view, illetve indexed view-k korántsem olyan hatékonyak, mint egy sima webszerver cache, mert ezek ha nem is olyan mértékben mintha elölről indulna mindegy egyes lekérdezés, de azért mozgatják az SQL-t. Az adatok felesleges mozgásáról, felesleges SQL-hez fordulásokról nem is beszélve. Szvsz nem is arra lettek kitalálva, hogy kvázi cache-t alkossanak bizonyos táblák felett, inkább az indexelt lekérdezéseket könnyítik meg nagyon komplex lekérdezéseknél (legalábbis MSSQL vonalon, ott használtam már indexed view-t).
-
-
#1525
csabyka666
veterán
bpx
#1524
-
#1523
csabyka666
veterán
bpx
#1522
Hm, ez igaz. A lényeg, hogy én úgy akarok felvenni minden alkatrészt, hogy megadom a felvételnél, hogy melyik autótípusokba lehet beépíteni. Itt jön a következő gond, hogy például ugyanazt a féktárcsát beépíthetem 8 féle autótípusba is, akkor azt a rekordot 8x kell felvennem, csak más autókkal?
-
#1521
csabyka666
veterán
bpx
#1520
-
Lacces
őstag
és lakisoft, köszi.
Akkor már csak annyi kérdésem lenne, hogy hogyan lehet tábla szerkezetet és adatokat egyik adatbázisból a másikba könnyen átvinni?
Elsősorban PostgreSQL-ből Oracle-be történő adat migráció érdekel. (csak az egyiknél lenne kérdéses... ha bevállik a weblap, akkor a többi weboldalhoz képest, rengeteg adat tárolódna és mozogna benne egy nap - vagy simán kudarc lesz )
De lehet akkor már lesz elég nyereség és felfogadok innen valakit a PH-ról, hogy oldja meg.
Csak nem akarom a kezdők hibáját elkövetni és már az elején elrontani.A válaszokat meg már előre köszönöm
-
Lacces
őstag
Kliensekre volt felrakva, a db szerver...
Igen, ezt a leírást én is láttam, meg olyat is olvastam, hogy 1 gépen 1 adatbázis szerver legyen.
" and use one CPU on the host machine."Csak az a gondom, hogy én szeretnék VPS-t bérelni, amin futna olyan 4-6 oldal lenne rajta, 1 mongodb és egy rdbms is.
1GB ram, 2magos cpu, 50GB-ra menne, és nem tudom mennyire bírná a szerver. Esetleg ilyen tapasztalatod van ezügyben? -
90% üzemeltető + 10 % fejlesztés. Oracle + MS. De perpill csak nagyon alapok vannak. Nem tudom ismered-e, de CCNA vizsgára vannak szuper könyvek, amikből el lehet sajátítani nemcsak a Cisco berendezéseket, hanem a hálózatokat is. Na, szóval ilyen kellene adatbázisokra, ha létezik
-
#1217
Sk8erPeter
nagyúr
bpx
#1215
Sk8erPeter
nagyúr
Na, a kérdés maga annyira megzavart, hogy már én is félrebeszéltem, meg pontatlanul is írtam, bocsi. A kérdező azt írta, hogy "A dátum 2003.11.26. 10:28:14 ilyen formátumban van.", én ebből úgy értelmeztem, hogy valamilyen oknál fogva string típusként van TÁROLVA az adatbázisban (most szándékosan írtam tárolást!! Mindegy, hogy varchar vagy egyéb ilyen jellegű típusról van szó, és NEM a dátumformátumok valamelyikéről, aminek nyilván megvan a maga tárolási módja, de attól még valamelyik tényleges dátumformátumról van szó), ezért kénytelen vagdosni, stb., de akkor valószínű félreértettem az eredeti felvetést.
Utána már azt is félreértettem, amit Te írtál, pedig így másodszor elolvasva elég világos, hogy itt csak dátum-megjelenítési formátumot változtatsz, attól még nem tárolod másik formában.
Akkor most megpróbálom értelmesen megfogalmazni: arra gondoltam, hogy még a megjelenítési formátumot sem biztos, hogy szerencsés, ha az ember változtatja, mert ha mondjuk egy alkalmazást megír (hogy most az asztali vagy webes, tök mindegy), ami az adatbázistól bizonyos formátumban (megjelenítési formátumban) vár adatokat, és tök más formában kapja meg, mint egy másik szerveren, akkor abból adott esetben probléma lehet - mondjuk a probléma kimerül annyiban, hogy át kell állítani a formátumot úgy, ahogy mutattad, de nem biztos, hogy azonnal leesik, mi is a gond. -
PazsitZ
addikt
Igen, mérés esetén vagy a benchmark-al futtasd le mondjuk 10000 ismétléssel így mindegyik esetén azonosan használ cache-t a későbbi requestek esetén és hamarabb kibukik.
Vagy mindkettő futtatása elé szúrd be a: RESET QUERY CACHE; parancsot.
Feltéelezve, hogy mysql-t használsz.
Vannak gepeink, amik adatbazisbol es adatbazisba dolgoznak. Nekem annyi kell csak, ha keresek benne valamit, akkor megtalaljam.
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
- BESZÁMÍTÁS! Logitech G923 kormány + Driving Force Shifter garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte B760M i5 14600KF 32GB DDR4 1TB SSD RX 6700XT 12GB Zalman Z1 Plus Seasonic 650W
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged