fogalmam sincs, mit csinál windows alatt.
nem csak a shared_buffer számít, a prepared statementeknek meg a connectionöknek is foglal memóriát, illetve van egy work_mem változó, azokat is érdemes csökkenteni.

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

MS SQL-ben kellene a táblákat és megírt nézet/függvény/SP-kel kilistáznom hogy a készítés dátuma is rajta legyen?
Valami tipp?

Táblákra van egy ilyenem:
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name, create_date
FROM sys.tables
ORDER BY schema_name, table_name

Antonio Coimbra de la Coronilla y Azevedo, bizony!

A sys.objects-ben megtalálsz minden user által létrehozott objektumot. A sys.system_objects-ben a system által létrehozott és a sys.all_objects-ben pedig mindekettőt.

Ahogy a leírásban is benne van a különböző objektumok nevét megkaphatod az OBJECT_NAME függvény segítségével.

Szűrsz a neked szükséges típusokra és meg is vagy.

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Rollback, commit, savepoint miképp működik?

Parancs alá írom vagy után mint egy új parancsot és együtt futtatom? Elolvastam a dokumentációt de most nem volt onnan világos a parancs működése.

Commit gyakorlatilag mindenki számára láthatóvá teszi a változást pl egy UPDATE esetén?

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

milyen sql?
MS SQL-nél begin tran-nal együtt kell futtatni az update-t, hogy rollback-elhető legyen.

Oracle

Jogos, elfelejtettem!

[ Szerkesztve ]

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Egy tranzakcióban futó adatmanipulációs (DML) utasítások (insert, update, merge, delete...) hatását csak az őket futtató DB session látja, amíg a tranzakció nincs commitálva.

Mittudomén, van egy táblád, amiben van 10 rekord.

Nyitsz egy adatbáziskezelő ablakot, amiben kiadsz 5 insertet, meg 3 updateet, majd kiadsz egy select count(*) from tabla;-t, akkor az ott 15-öt fog mutatni.

Közben nyitsz egy másik ablakot, egy ott kiadott select * from tabla; az eredeti állapotot, 10 rekordot fog mutatni, a még nyitva lévő tranzakcióban hozzáadott ötöt, meg az updateek hatását nem!

Ha az első ablakban kiadsz egy commit;-ot (amivel véglegesíted az addig nyitott tranzakcióban futtatott DML utasítások hatását és lezárod a tranzakciót), akkor a második ablakbeli select *-ot újrafuttatva már 15, módosult rekord fog megjelenni.

Ha az első ablakban commit; helyett rollback;-et nyomsz, akkor teljesen eldobódik a nyitott tranzakcióban futtatott DMLek hatása, és visszaáll az eredeti állapotra.
Tehát ha utána kiadnál egy select *-ot, akkor ugyanazt a 10 eredeti rekordot látnád az első ablakban is, mint korábban a kettes ablakban.

Adatdefiníciós (DDL) utasítások (pl. tábla létrehozás, eldobás, oszlop hozzáadás, index létrehozás...) mindig önálló tranzakcióban futnak és azonnal commitálódnak, így azok nem vonhatóak vissza kiadás után.
Meg ha jól rémlik, akkor az adott DB sessionben még függőben lévő tranzakciót is commitálják!

Savepointokat még nem használtam, de ahogy olvasom arra jó, hogy rollbacknél meg lehessen mondani, hogy ne az egész addigi tranzakciót dobja el, hanem csak a savepoint után futtatott utasításokat.

Lehet, hogy valakik szerint ez jó ötlet, de alapvetően sérti a tranzakciók atomiságát, és jóval nehezebb egy félig lefutott tranzakció által elcseszett adatokat javítani, mint ha eldobnád az egészet a francba, és javítás után elölről újrafuttatnád az egészet.

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

ott alapból tranzakcióban fut, de vannak még lehetőségek:
[link]

MS SQL-nél begin tran-nal együtt kell futtatni az update-t, hogy rollback-elhető legyen.

Nem lehet az SSMS beállításainál kikapcsolni az autocommitot?

De, pirosat be kell pipálni, mert nem az a default:

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

MS SQL-nél begin tran-nal együtt kell futtatni az update-t, hogy rollback-elhető legyen.

Nem lehet az SSMS beállításainál kikapcsolni az autocommitot?

De, pirosat be kell pipálni, mert nem az a default:

Ezután nem fogja automatikusan commitálni a kiadott utasításokat.

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

köszi, ezt nem tudtam, hasznos infó.

Köszönöm! Életmentő volt holnap lesz csak órai téma de így végre letudom adni a félévest teljesen befejezve és nem kell már vele szórakozzak a héten, legalább ezzel kevesebb!

Keresgéltem de stackover után sem esett le teljesen a dolog pedig tényleg egyszerű...

Érdekes mindig ezekkel az egyszerűbb cuccokkal szenvedek, a tárolj eljárásos, függvényes triggeres téma valahogy jobban feküdt de sanszos, hogy a prog miatt.

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Még annyit érdemes tudni a többiek által leírtakon túl, hogy van egy TRUNCATE TABLE parancs, ami ugyanúgy kitöröl mindent egy táblából mint a DELETE parancs, csak DDL utasításként viselkedik, tehát azonnal végrehajtódik és nem is lehet rollback-elni. A DELETE-et a tranzakción belül még igen. Cserébe villámgyors. A DELETE az sok rekordra nagyon lassú tud lenni.

Illetve a truncate alapállapotba hozza a táblához tartozó indexeket, incrementeket is. Delete meg tényleg csak az adatot törli.

Én kérek elnézést!

Persze hogy lassú a DELETE, mert az törlendő soronként módosítja az indexeket, hívogatja a triggereket, plusz vezeti az undo logot.

TRUNCATE meg egy lépésben mindent legyalul a francba, és nem is logol sehova.

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

Köszönöm, összeszedtem ami kellett.

Antonio Coimbra de la Coronilla y Azevedo, bizony!

Köszönöm a válaszokat!

Még annyi kérdésem lenne( ), hogy ha adtam SESSION létrehozáshoz is jogos egy usernek, miért nem látja az adott séma tábláit?
Elméletileg pedig kéne lássa nem?

CREATE ROLE raktáros IDENTIFIED BY r123;
    CREATE ROLE eladó IDENTIFIED BY e123;
    CREATE ROLE üzletvezető IDENTIFIED BY ü123;
    CREATE USER Zolika IDENTIFIED BY z123;
        GRANT UNLIMITED TABLESPACE TO Zolika;
    CREATE USER Toma IDENTIFIED BY t123;
        GRANT UNLIMITED TABLESPACE TO Toma;
    CREATE USER Csilla IDENTIFIED BY c123;
        GRANT UNLIMITED TABLESPACE TO Csilla;
        GRANT CREATE SESSION TO Toma;
        GRANT CREATE SESSION TO Csilla;
        GRANT CREATE SESSION TO Zolika;
    GRANT SELECT, INSERT, UPDATE, DELETE ON kereskedes TO eladó;
    GRANT SELECT, INSERT, UPDATE, DELETE ON motorok TO eladó;
    GRANT SELECT, INSERT, UPDATE, DELETE ON kiegeszitok TO eladó;
    GRANT SELECT, INSERT, UPDATE, DELETE ON adasvetel TO eladó;
    GRANT ALL PRIVILEGES TO raktáros; 
    GRANT SELECT ON kereskedes TO üzletvezető;
    GRANT SELECT ON adasvetel TO üzletvezető;
    GRANT SELECT ON motorok TO üzletvezető;
    GRANT SELECT ON kiegeszitok TO üzletvezető;
    GRANT SELECT ON maganszemely TO üzletvezető;
    GRANT raktáros TO Zolika;
    GRANT eladó TO Csilla;
    GRANT üzletvezető TO Toma;

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Ha jól értem most a táblák a hr user alatt "maradtak" mert ott hoztam létre ergo meg kell nevezzem a hr.-rel őket ha nem akarok ANY-vel teljes database wide jogot adni?

Így sem "léteznek" a tábláim.

[ Szerkesztve ]

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

GRANTolni csak az tud, akié a tábla, vagy kapott rá GRANTolási jogot, vagy DBA júzer.
Akinek csak olvasási/írási joga van, az nem tudja azokat továbbadni!

Ha hr séma/júzer alatt hoztad létre a táblákat, akkor hr júzerrel kell kiadni a GRANTokat.

Utána a többi júzer select * from hr.táblanév;-vel fogja elérni őket.

Egyébként a táblák listája nyilvános, bárki lekérheti a select * from dba_tables;-t.
Ha a select * from all_tables;-t kérdezed, ott csak azokat mutatja az Oracle, amikhez az aktuális júzernek joga is van.

[ Szerkesztve ]

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

hr alól lettek létrehozva a táblák és ott is lett a GRANT kiadva mivel megkötés volt, hogy ne lehessen jogot tovább adni.

De nem akarja az igazságot annyira nem, hogy disconnect majd connect ismét hr-rel átraktam mindent ANY-re, hát nem igazán hatotta meg a dolog mert továbbra sem léteznek a tábláim.

edit.: ezt a DBA-t mindjárt megnézem csak nulláztam a vmwaret inkább berakok minden kódot újra mert kezdtem kuszálni már.

[ Szerkesztve ]

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Akkor kérdezd le:
select *
from dba_tables
where table_name='CSUPANAGYBETU';

(Oracle nagybetűsen tárolja a DB objektumok neveit.)

[ Szerkesztve ]

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

select *
from dba_tables
where table_name='MOTOROK'; és végig próbálgatva is ORA-00942 lesz az az: a tábla vagy a nézet nem létezik.

Pedig nulláról kezdtem:
Új kapcsolat Hr-be belépve, létrehoz és feltölt.
Kapcsolódtam a SYS as SYSDBA-ra megadtam az ALL PRIVILEGES-t a Hr-nek.
Létrehoztam a usereket és a role-okat, de semmi változás a dba_tables-re sem lehet lekérdezni.

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Köszi, megnézem akkor a work_mem-et is.

...valamiért magától észhez tért nem tudom miért. Újraraktam a virtuális gépet most jó.

A sor szintű trigger az a for each row ugye?
Ha tábla szintű triggert írtak még nekünk ott a költő mire gondolt? statement trigger-re?

The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.

Yep

Dokumentációja szerint a Postgre SIMILAR TO/NOT SIMILAR TO/~/~* operátoroknak egy patternt lehet megadni.

Úgyhogy nem úszod meg tárolt eljárás nélkül:
Kurzorba teszed a pattern lista tartalmát.
Végigiterálsz a kurzoron, minden egyes lépésnél egy ideiglenes táblába leválogatod az eredeti táblából az aktuális patternre illeszkedő értékeket.
Végén meg egy jól irányzott left joinnal kiválogatod az eredeti táblából azokat az értékeket, amik a másodikban NEM szerepelnek.

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

természetesen tud.
azért arra készülj fel lélekben, hogyha csinálsz egy nagyobbacska táblára full joint egy párszáz regexpes táblával, attól szédülni fog a cucc
át.

select keresendo from keresendotabla,regexptabla where keresendo ~ regexposzlop;

[ Szerkesztve ]

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

Hmm, így joinra nem gondoltam, jó ötlet.

Más kérdés a sebesség, regexp valószínűleg sehogy sem hasít.

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

Jó lesz az, csak halmazokban kéne gondolkozni.
Neked a regexp kifejezések uniójának negáltja kell, nem a negált regexpek uniója!

Vagyis left join on keresendo ~ regexp... where regexp is null.

bambano megoldását szabvány join szintaxisra átírva:
select keresendo
from keresendotabla
left join regexptabla
on keresendo ~ regexposzlop
where regexposzlop is null;

[ Szerkesztve ]

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

mindig jó ötlet az adatbáziskezelőn belül tartani a melót.
tehát ha meg tudod úgy oldani a programot, hogy ne kelljen kihúzgálni az adatot az sql szerverből, akkor az jobb.

ezzel szemben van az, hogy jelen esetben is elszállhat a memóriaigény.

legegyszerűbb kipróbálni és megmérni a lehetséges verziókat.

nálad probléma lehet, hogy ebben a megoldásban a regexp rámegy azokra a sorokra is, amiket egy korábbi regexp már kizárt, ami elég nagy pazarlás. tehát ha külső nyelvből csinálnád a keresést, akkor lehet, hogy egyszerűbb lenne úgy, hogy csinálsz egy temporális táblát, abba belerakod az összes adat azonosítóját, amit az első regexppel szűrtél és még kell, majd utána a többivel sorban kiszórod belőle azt, ami nem kell. ha a regexpeket gyakoriság szerinti csökkenő sorrendben teszteled, akkor az hatékonyabb lesz.

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

Ezzel viszont vissza is kanyarodtunk a kurzoron végigiterálós megoldáshoz, amit macerásabb megírni, mint az előbbi jólfésült selectet

nagy vonalakban valami ilyesmi:
declare
cursor c is
select regexp
from regexptabla
order by gyakorisag desc;

r varchar2(100);

begin
truncate temptabla;

open c
loop
fetch c into r;
exit when c%NOTFOUND;

insert into temptabla (voltmar)
select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null
and e.ertek ~ r;

end loop;
close c;

select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null;

end;

(Nem vágom a postgre szintaxisát.)

[ Szerkesztve ]

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

Unió az VAGYlagos kapcsolatot jelent, ÉS meg metszetet.

Neked az kell, hogy egyik regexpnek sem felel meg, azaz -regexp1 ÉS - regexp2 ÉS -regexp3... (komplementerek/negáltak metszete!)
Ezt ha levezeted, akkor azzal egyenlő, hogy -(regexp1 VAGY regexp2 VAGY regexp3...) (unió komplementere/negáltja!)

Mivel a táblák sorai között mindig VAGYlagos kapcsolat van (tábla a sorainak uniója!), így ez utóbbi azt jelenti, hogy az érték nincs a regexp tábládban.
A táblából meg úgy kapjuk meg a B-ben nem szereplő értékeket, hogy LEFT JOIN ... IS NULL.

[ Szerkesztve ]

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

Logika úgy diktálná, hogy egyezzen a kettő.

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

Sziasztok!

Bár ritkán adom fel, de ez most kifogott rajtam és a Google se segített.

Alap: SQL Server
Minta:

CREATE TABLE t1 AS (
  id int,
  name varchar,
  dependency int
);

INSERT INTO t1 VALUES (1,'n1',0);
INSERT INTO t1 VALUES (2,'n2',1);
INSERT INTO t1 VALUES (3,'n3',1);
INSERT INTO t1 VALUES (4,'n4',2);
INSERT INTO t1 VALUES (5,'n5',3);
INSERT INTO t1 VALUES (6,'n6',3);

SELECT DISTINCT ca.id
FROM t1 
LEFT JOIN t1 AS t2 ON t2.ID = t1.dependency
LEFT JOIN t1 AS t3 ON t3.ID = t2.dependency
CROSS APPLY (
  SELECT t1.ID UNION ALL
  SELECT t2.ID UNION ALL
  SELECT t3.ID ) AS c (id);

A nagy kérdés, hogy én komfortosabb vagyok a JOIN-okkal, mint az APPLY-okkal. Ezt bevallom értelmezni se tudom. Az megvan, hogy egy hierarchiát épít, de a CROSS APPLY esetén a (id) kicsit fura, mert melyik ID-val köti össze a CROSS APPLY-ban lévő ID-t? Vagy duplikálna? A kód szerzője ismeretlen

Valami ilyesmi lenne?

SELECT DISTINCT ca.id
FROM t1 
LEFT JOIN t1 AS t2 ON t2.ID = t1.dependency
LEFT JOIN t1 AS t3 ON t3.ID = t2.dependency
LEFT JOIN (
  SELECT t1.ID UNION ALL
  SELECT t2.ID UNION ALL
  SELECT t3.ID ) AS c ON t1.ID = c.ID OR t2.ID = c.ID OR t3.ID;

[ Szerkesztve ]

Mess with the best / Die like the rest

A Cross Apply-t nem tudod Joinra fordítani, talán leginkább a FULL OUTER JOIN hasonlít hozzá. Ebben az esetben duplikálni fog.

Én kérek elnézést!

Amúgy csak megérteni szeretnéd, vagy átírni?

(Kis csiszolgatás után) beraktam beraktam sqlfiddle-be a mintádat, de nem sok értelmeset produkált: (null),1,...6-ig hozta az összes ID-t

Ha esetleg szeretnél hierarchiát építeni SQL Serverben arra ott a rekurzív CTE

Köszi mindkettőtöknek! Amúgy oracle-re fordítás a cél, de értelmezni se ártana. A join jogos. Siettem. Full outer a nyerő.

Mess with the best / Die like the rest

Szeretném megcsinálni azt, hogy vannak partnereink akik sajnos valami folytán kétszer kerültek be az adatbázisunkba és szeretném a kölcsönzéseiket összevonni az újabb regisztrációba.

Név és telefonszám alapján le is tudom kérdezni a listát ahol látom az összes duplikációt.
A lényeg az lenne, hogy a régebbi partnerhez tartozó kölcsönzéseket átrakjam az új partnerre.
A kölcsönzések tábla tartalmazza természetesen a partnerid-t, így ott kellene valahogy kicserélnem a régi az újra.

Itt e lekérdezés a duplikációkra itt szépen látom az id-t, a nevet és a telefonszámot.
SELECT
    y.id,y.nev, y.Kapcsolat
    FROM Partnerek y
        INNER JOIN (SELECT
                        nev, kapcsolat, COUNT(*) AS CountOf
                        FROM Partnerek
                        GROUP BY nev, Kapcsolat
                        HAVING COUNT(*)>1
                    ) dt ON y.kapcsolat=dt.kapcsolat  order by Kapcsolat
[kép]

En felvennek egy segedmezot, ami a "vegleges" azonositot tartalmazna. Idokozonkent befrissitenem. Az elv az lenne, hogy a duplikatumokckozul azoknal, amelyekre nincs szukseg, feltoltod.

jó az irány.
még group by-old a külső select-et névre és telefonszámra, és az id-t MIN()-eld.
ezt mentsd el egy temp táblába, majd a temp táblához join-old be a partner táblát, név és telefonszám alapján + temp.ID <> partner.ID
így meglesz egy rekordban a duplikált partner régi és új id-ja, ezzel már könnyen meg tudod írni az update-t, hogy a kölcsönzés táblában mit mire kell cserélni.
+ én még a partner táblát bővíteném egy oszloppal, hogy törölt / archív, és a régi id-ek megjelölném, így később ki lehet őket szűrni.

Nagyon szépen köszönöm az iránymutatást, sikerült is megcsinálni.