- Álláskeresés, interjú, önéletrajz
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- Mikrotik routerek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Ubiquiti hálózati eszközök
- Netflix
- Windows 11
- A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
- Aliexpress tapasztalatok
- Windows 10
Új hozzászólás Aktív témák
-
#65304576
törölt tag
Eltartott egy ideig, mire értelmeztem, de azt hiszem, értem. Tehát van egy többé-kevésbé bonyolult képleted (kivonás), amit egy csomó más helyen is használni szeretnél ugyanazon select-en belül, és ezért szeretnéd először kiszámolni, majd a többi oszlopnál is valamiféle változót használni.
A probléma csak kényelmi és vizuális ("csúnyán néz ki"), performanciára nincs hatása, mert az első kivonás eredménye kvázi konstansként behelyettesítődik majd a többi képletbe is (a parser felismeri az azonos kifejezést).
Az Oracle-nek egyébként nincs inline változója, bár al-select-ekkel (inline view, vagy with ... as) megoldható a dolog, azzal igen valószínű, hogy csak rosszabbul jársz.
Szóval marad a ctrl+c / ctrl + v. (Vagy a pl/sql, de az is lassabb lesz.)Ha a kifejezést máshol is használni kellene (pl. where-ben), akkor már esetleg lehet gondolkozni azon, hogy előre kiszámolni és primary key alapján visszakötni a főtáblához, immár egyszerű oszlopként. Pl.:
with sub_diff as ( select id, end_time - start_time mp_diff
from table1 where (end_time - start_time) < 5 )
select d.data1 / t.mp_diff, d.data2 / t.mp_diff, d.data3 / t.mp_diff
from sub_diff t, table1 d
where d.id = t.id[ Szerkesztve ]
-
#65304576
törölt tag
válasz EEdem_Dtx #293 üzenetére
A "DBA..." kezdetű nézeteket csak DBA joggal (role, nem összekeverendő a SYSDBA-val ) lehet látni. De ezeknek van "USER..." és "ALL..." nevű változata is. Az előbbiek minden olyan adatbázis objektumot tartalmaznak, amelyek az adott user tulajdonában (owner) vannak, az utóbbiak pedig mindazokat is, amelyeket valaki más kiajánlott neki GRANT-tal, vagy amelyek publikusak (a PUBLIC-nak lettek kiajánlva).
Esetedben az átlag user használhatja az user_tab_cols, all_tab_cols nézeteket - ha a tábla az övé, vagy joga van legalább SELECT-et futtatni rajta, vagy publikus.Demó adatbázisban a scott/tiger-nek adhatsz mindenféle jogokat, de élesben ne tedd (a sémát se tedd fel). Emellett soha ne írj olyan pl/sql scriptet, ami ilyen problémát ideiglenes GRANT-tal próbálna megoldani.
-
#65304576
törölt tag
Egy trükk Oracle-hez, máshol nem valószínű, hogy működik:
Az alapprobléma az, hogy tulajdonképpen egy folyamatos sorszám halmazt kellene előállítanunk, ami 1-től indul és valameddig tart. Naptár esetén értelemszerűen napokkal, de bármire jó lenne egy ilyen.
Nos, ezt így kell megoldani:SELECT LEVEL cnt FROM dual CONNECT BY LEVEL <= 100;
Ez visszaad egy táblát, amelyben minden rekord egymás után következik és csak sorszám (konkrétan 1-től 100-ig). Ha ezt összekötjük azzal, hogy Oracle-ben (is) a dátumtípus és a numerikus értékek között lehetségesek műveletek és az 1 (egy) pontosan egy napot jelent, már készen is van egy táblánk, ami tetszőleges dátumsort képes megjeleníteni. A tábla csak a memóriában létezik, nem kell tárolni, nagyon gyorsan képezhető, beágyazható, kaphat alias-t, stb., mindent lehet vele csinálni. Pl.:
select
days.next_days,
to_char(days.next_days, 'DAY') name_of_day,
to_char(days.next_days, 'D') day_of_week
from
(SELECT trunc(sysdate) + LEVEL next_days
FROM dual CONNECT BY LEVEL <= 7) days;Kisebb intervallumokra sokkal gyorsabb megoldás, mint a több táblás join.
[ Szerkesztve ]
-
#65304576
törölt tag
válasz Sk8erPeter #974 üzenetére
Ez már rég nem így van. Komoly helyeken ma már elvárás, hogy az adatbázis rendszeradminok ne férhessenek hozzá érzékeny adatokhoz, még DBA jogokkal sem. Részben törvényi előírás, részben céges policy lehet ennek az oka. Egy DBA pozíció nagyon kemény bizalmi állás, nekem is nagyon sok feltételt és kikötést kellett aláírnom és elfogadnom. Emellett a nagyobb, komolyabb rendszerek már mind rendelkeznek valamilyen védelmi eszközzel ilyen esetekre, ilyen pl. az Oracle Vault.
És Oracle DB-ben lehet oszlopra is jogosultságot definiálni, de ha nem kell, az adatbázis szintű auditálással is ellenőrizhető, hogy ki mihez fért hozzá, nem kell hozzá külön log-olást gyártani.
-
#65304576
törölt tag
válasz Sk8erPeter #976 üzenetére
Attól függ, milyen jogosultságkezelésről beszélünk. Az adatbázis szintű és alkalmazás szintű két külön dolog, én az előbbiről beszéltem. Egy több ezer felhasználós alkalmazás simán használhat egyetlen adatbázis user-t. Itt természetesen az alkalmazás oldali jogosultságok kezelésén van a hangsúly. Ma már ritka (és szerintem jócskán elavult) az olyan alkalmazás, amely minden user-t külön db user-ként kezel, itt a jogosultságkezelés egyértelműen a db-ben kell legyen.
Viszont ma már nem egyszintű rendszerekről szoktunk beszélni, hanem egymással szoros kapcsolatban lévőkről, köztes interfészekről, akár közös adatbázison osztozó rendszerekről is. Itt a rendszerek közötti jogok kezelése alkalmazás oldalról értelmetlen (nem számítva a speciális middleware és ESB-szerű termékeket). -
#65304576
törölt tag
Új hozzászólás Aktív témák
- Gigabyte Brix GB-BRR3H-4300 4300u, 16GB DDR4, 256GB SSD
- HP Probook 450 G5 - 8th Gen i5/8GB/128GB
- Ritkaság! Alienware AW5520QF Oled Gamer Monitor!55"/4k/120hz/0,5ms/Alienfx RGB
- LG34UM68-P 21:9-es Ultra Wide monitor eladó!
- HP Envy x360 15,6 IPS LED Gorilla Glass i7, 16GB, 1TB fémházas 3az1 notebook + HP toll - harmad áron