PostgreSQL 9.3

PostgreSQL

A PostgreSQL Global Development Group bejelentette a nyílt forrású PostgreSQL 9.3-as verziójának elérhetőségét. Főbb változások:

Részletek a What's new dokumentumban, a kiadási megjegyzésekben és a bejelentésben.

( bra | 2013. 09. 09., h – 17:07 )

A következő évtizedre kb. utol is éri az Oracle-t a 99%-ban használt feature-öket tekintve, és akkor világuralom! :)
--
zsebHUP-ot használok!

Egy jól belőtt Oracle-nél nem hiszem, hogy gyorsabb tud lenni.
Azért Oracle-éknek van pár év előnyük a fejlesztésben.
MySQL vs PostgreSQL más téma, ott már értek meglepetések. :)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen lehet,de megéri? Az Oracle költségen, dupla akkora vasat veszek, akkor már biztos nincs sebességkülönbség. Az más kérdes, ha nincs más választásom, mert olyan feature kell ami csak az oracleban van.
Amiben az Oracle-nek előnye van az a cluster,RAC,GRID technológiák.

Óvatosan a szakkifejezésekkel! Oracle-ben a cluster mást (is) jelent. ;)

Hogy megéri-e? Anno úgy voltam vele, hogy a support miatt, igen. Mióta tapasztaltam, hogy mire megyek egymagam a supportjukkal, azóta vannak kétségeim. :)
(más kérdés, hogy jól fizető ügyfélhez anno kiküldtek embert, egyik oktatójuk hozzánk is kijárt és ő valóban értett is hozzá, segített is mindenben)

Azért a skálázhatóság, biztonság terén is van előnyük, nem kevés. A többit nem ismerem, de az Oracle RDBMS-e egy mini op.rendszernek is tekinthető. (9i környékén akadtam el)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen a clustert mint active lábakból álló fürtként gondoltam. Mint alkalmazásfejlesztő, látom hogy a modern alkalmazások, frameworkok(j2ee,.net, spring, jpa), gyakorlatilag az adatbázisok kis részét használják. Itt eltűnik a különbség a postgres, oracle között.
Az oracle sokmindent tud, de nagyrészére nincs szükség. Pl ki az az elvetemült aki java-ban akarna tárolt eljárást írni, lehet de minek.

Miért? Pythonban ki akar? PostgreSQL-nek meg asszem van ilyen lehetősége. ;)
Kis cégeknél nem látom értelmét, de mondjuk egykori munkahelyemen azért volt rá kereslet.
Mást ne mondjak: audit funkció hány adatbázisban van?
(lehet, hogy van, én eddig csak oracle-ben láttam)

És hát üzemeltetési szempontból számomra kellemesebb volt az Oracle, mint így utólag bármely másik, open source.
De ez már erősen szubjektív vélemény.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nagy cégnél, ahol ezek szempontok fontosak, én is azt mondom Oracle, mert ott fontos a support, a rendelkezésre állás, a security. De sokszor teljesen fölösleges, egyszerűen a projectmanager, architect benyögi hogy Oracle, és a project költségének nagy rész elmegy vasra, és licence költségre a fejlesztésre meg alig marad pedig csak pár GB adatbázison futkároznak egyszerű selectek.

De minek korlátoznám be magam XE-vel, amikor a Postgre teljesen jó lesz akkor is, amikor 5 év múlva 10 GB-os lesz az adatbázis. Nem az a lényeg mekkora az adatbázis, hanem milyen query-k futnak. Egyébként fejlesztettem pénzügyi reporting alkalmazást 20-50 GB-os DB-n, 100-200 tábla, nagyon komplex query-k és a postgres nagyon jól bírta, nagyon jó a query planner-je.

Az trigger, nem audit.
Most nem másznék bele mélyebben.
Ha érdekel, küldhetek saját gyártású doksit az oracle auditról ;)
(Nem munkahelyi, hobbiból írtam valakinek)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Lehet, hogy nem hallani rola, de hasznalatban van, eleg kiterjedt mertekben. Jo velemenyem nekem speciel se az Oracle-rol, se a Db2-rol nincs. Mindketto tularazottnak/hypeoltnak erzem.

Mondjuk en foleg db felhasznalo/alkalmazas fejlesztes oldalrol latom oket, nem uzemeltetesi szempontbol. Viszont a tapasztalataim alapjan en azt mondanam, hogy meg az ugy mond "enterprise" feladatok nagy reszere is tok feleslegesek ezek a cuccok. A nagy reszukre a Postgre tokeletesen megfelelne. Foleg azokon a helyeken, ahol az Oracle-t ugy hasznaljak, mintha egy Excel lenne: se PK, se FK, se indexek, se semmi (es erre volt pelda ismert, Magyarorszagon is mukodo, nemzetkozi nagy cegnel). Kesz kidobott penz a licensz.
Nekem inkabb ugy tunik nincs manager enterprise kornyezetben aki eleg tokos lenne, hogy azt mondja neki nem kell Oracle/Db2 jo egy Postgre is. Nem az o penzebol megy, ez a riziko mentes valasztas...

Apropo DB2. Most, hogy mondod: abból van "embedded" verzió is! :)
Sok IBM termék lebutított DB2-t használ adatbázisként úgy, hogy ha nem mászol bele a doksijába elég mélyen, talán észre sem veszed. Azt hiszem, pl. a Tivoli OnDemand (vagy valami ehhez hasonló nevű) szoftver is egy minimalizált DB2-ben tárolja a katalógusait, meg valami rémlik, hogy az MQSeries is ilyesmit használ alapállapotban.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ha választanom kell akkor 100x inkább Oracle mint DB2. A DB2 nagyon jól hangolható, de cserébe alapból nagyon rossz beállításai vannak, és egy pilótavizsga kell a kezeléséhez. Ahhoz meg hogy egy sql sebességét be tudjam optimalizálni, meg 3 fajta tool, meg nap és hold állása, és fekete kakas vérével kell körbelocsolni a szervert. Egy rémálom, ezzel szemben porstgre-ben explain ,analyze és már meg is van hol a baj. A másik az a db-khez kapcsolódás baromságai amitől falra tudok mászni XXI. század miért kell TNSNAMES-eket szerkeszteni, adatbázisokat katalogizálni, amikor csak csatlakozni szeretnék az x ip-n y porton futó db-hez, miért kell ezt túlbonyolítani.

Szerintem ez már a 9i-ben is megvolt.
Én csak arról beszélek, hogy nem kell tnsnames-t szerkeszteni.
Bár rég volt, előfordulhat, hogy rosszul emlékszem.
És az is igaz, hogy többnyire jdbc thin drivert használtam hozzá. :)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Én voltam olyan elvetemült, hogy Oracle DB-ben tárolt eljárást Java-ban készítettem el. :-) PL/SQL-ben elég nehéz lett volna 8i/9i alatt LDAP autentikációt írni. Ez még akkoriban volt, amikor komplett rendszereket PL/SQL-ben írtunk meg és a Java tárolt eljárás tűnt a legfájdalommentesebb megoldásnak az LDAP autentikáció megvalósítására. Így a teljes kód maradhatott az adatbázisban.

:)
Egyébként röhej, de amíg dolgoztam az Oracle-lel, nem igazán fogtam fel a PL/SQL-t. Szükségem nem volt rá, tudomásul vettem, hogy ilyen is van, de hogy én magam megírjak benne valamit, arra képtelen voltam.
Már rég nem dolgoztam, mikor PHP-ben kicsit belemásztam olyasmikbe, mint a PDO (a hagyományos mysql helyett) és akkor értettem meg sok mindent, amit korábban nem.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Meg attól is függ, hogy veszek supportot a Postgres-hez is, ami kijön évi pár ezer euroból, és nem processor függő. Meg hát tudjuk, ha nagy ügyfél vagy akkor egyedi árakat tudsz kialkudni, főleg ha bevezetésről van szó. A dealerek előszőr olcsón adják hogy hozzászokj az anyaghoz, majd később elemik az árát.

( NagyZ v | 2013. 09. 10., k – 23:34 )

ha a materialized view updateje triggerelodne egy belso dependency update utan, na, az kiraly lenne. ahogy nezem ezt nem tudja.