Új hozzászólás Aktív témák

• #3611 #65304576 törölt tag Torry #3606

  Új Válasz 2017-10-26 17:05:48 #3611

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz Torry #3606 üzenetére

  Sőt: http://www.firebirdfaq.org/faq46/

• #1004 #65304576 törölt tag D@ni88 #1003

  Új Válasz 2012-03-12 12:43:15 #1004

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz D@ni88 #1003 üzenetére

  Nézz rá az "execute immediate ..." szintaxisára. De ez elég csúnya dolog szokott lenni, én inkább a logikán változtatnék.

• #979 #65304576 törölt tag martonx #978

  Új Válasz 2012-02-10 14:13:03 #979

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz martonx #978 üzenetére

  Tökéletesen ugyanarról beszélünk.
  (Nem akartam túlzottan szakszavakat használni, de már látom, hogy szerencsésebb lett volna az adatbázis szintű usereket sémának hívni, így nem lett volna félreérthető.)

• #977 #65304576 törölt tag Sk8erPeter #976

  Új Válasz 2012-02-10 11:23:25 #977

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #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).

• #975 #65304576 törölt tag Sk8erPeter #974

  Új Válasz 2012-02-10 08:01:44 #975

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #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.

• #906 #65304576 törölt tag martonx #884

  Új Válasz 2012-01-31 13:22:17 #906

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz martonx #884 üzenetére

  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.

• #337 #65304576 törölt tag tkazmer #335

  Új Válasz 2008-04-09 08:55:07 #337

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz tkazmer #335 üzenetére

  Nem írtad, hogy milyen adatbázis kezelő alatt.

  Oracle-nél használható a length() függvény ORDER BY-ban is. Vigyázat: CHAR típusú mezők esetén a visszatérési érték mindig a mező max. szélessége!

• #311 #65304576 törölt tag EEdem_Dtx #293

  Új Válasz 2007-12-07 13:33:14 #311

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #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.

• #282 #65304576 törölt tag _Lord_B_ #281

  Új Válasz 2007-11-08 08:05:59 #282

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz _Lord_B_ #281 üzenetére

  Más karakterkészlettel megy ki a weblap. Nézd meg, hogy a PHP Admin hogyan küldi (jobbklikk a lapon - properties) és ugyanolyan kódkészlettel generáld te is a header-t.

• #280 #65304576 törölt tag lapa #279

  Új Válasz 2007-10-12 22:06:43 #280

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #65304576

  törölt tag

  válasz lapa #279 üzenetére

  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

Új hozzászólás Aktív témák