Oracle - Sun
bullet Crystal -- 2010-01-26
Na most hogy az oracle-nek végre sikerült elég EU-s nagykutyát lefizetni ahhoz hogy megvehesse a Sun-t, úgy érzem itt az ideje hogy én is pampogjak valamit az üggyel kapcsolatban.

Kezdjük talán azzal a fölöttébb aktuális dologgal (az utóbbi napokban sokan blogoltak ezzel kapcsolatban), hogy mi lesz a Java-val. Sokan attól félnek hogy az oracle be fogja zárni a platform eddigi meglehetősen nyílt fejlesztését, de ez szerintem hülyeség. A Java technológiák attól életképesek és azért tudják felvenni a versenyt a .NET-tel, mert sok cég részt vállal benne: sun, redhat, ibm, google, oracle stb (most többet mondjuk nem tudok). A Sun ügyesen menedzselte a rendszert, alapvetően specifikációkat (JCP - Java Community Process) és referencia-implementációkat adott ki (pl. alkalmazásszerver, JPA stb), és a speckót bárki maga is implementálhatta. Ez belső versengést idézett elő a platformon belül, amiben a fent említett cégek részt vettek, és így van alternatíva minden lényeges dologra. Ez így faszán működik, ha jól tudom akkor 3x annyi a Java-s szoftverfejlesztés mint a .NET-es (fixme). Namost nyilván igaz hogy az oracle-re nem jellemző hogy ingyen adjon/nyílt kóddal adjon jó dolgokat, de ez nem jelenti azt hogy hülyék és rá fogják kényszeríteni teljesen a saját üzleti modelljüket a Sun-ra. Lehet hogy a specifikációk kialakításába kevesebb beleszólást engednek majd külsősöknek, de ezt eddig is 80%-ban a Sun végezte, meg vétójoguk is volt, magyarul nem dől össze a világ ha ezt mostmár teljesen az oracle csinálja. Annyira meg aztán tényleg nem hülyék, hogy az egész java platformot bezárják és maguk akarják fejleszteni, akkor az lenne a helyzet hogy Oracle (Java) vs. Microsoft (.NET), ezt pedig nyiván nem érdemes bevállalni. Magyarul röviden a Java miatt senkinek nem kell sipítozni szvsz.

Na nézzünk még meg néhány Sun terméket: a SPARC architektúrát nyilván fejleszteni fogják, baromira megéri hosszabb távon hogy saját hardvert fejleszthetnek a DMBS-ük alá, még akkor is ha perpill nem túl izmos a SPARC platform.

A NetBeans már kicsit húzósabb, van ugyanis az Oracle-nek egy JDeveloper nevű Java IDE-je, ami mondjuk nem túl elterjedt, a NB viszont gyorsan fejlődik, sokan használják és van körülötte közösség, meg üzleti modellt se nehéz tenni alá (már ha perpill nincs), úgyhogy én nem féltem. Az OpenOffice viszont elég gáz, nem hiszem hogy az Oracle-nek megéri irodai szoftvercsomagot fejleszteni - főleg nem ingyeneset - úgyhogy nem lennék meglepve ha elsorvadna az OOo (a community tuti nem fogja életben tartani eddig is 80%-ban a Sun fejlesztette). A MySQL meg gyakorlatilag szintén felejtős, ha úgy nézzük kb semmire nem kötelezte magát végül az ora a fejlesztésével kapcsolatban, viszont van helyette PostgreSQL úgyhogy pótolható, nekem a magam részéről nem fog különösebben fájni a szívem ha bedől a MySQL.
PL/Java
bullet Crystal -- 2009-04-10
A PL/Java egy olyan addon PostgreSQL-hez, melynek segítségével Java-ban írhatunk triggereket az adatbázisunkhoz.

A triggerek tárolt eljárások az adatbázisban, melyek adott esemény előtt vagy után futnak le (az esemény lehet valamelyik táblán insert, update vagy delete query). Különböző adatbázisok nagyon eltérő módon szemlélhetik a triggereket, pl. MySQL-ben a trigger egy SQL lekérdezés, postgresql-ben egy valamilyen programnyelven megírt függvény. Triggereket elsősorban akkor érdemes használni, ha több alkalmazás használja ugyanazt az adatbázist. Ilyenkor az adatok konzisztenciájára, "szabályosságára" minden alkalmazásban külön-külön kellene figyelnünk, így jelentős mennyiségű duplikált kód keletkezik, de ha ugyanezt az alkalmazások alatt, az adatbázisban oldjuk meg triggerekkel, akkor nincs ilyen probléma.

A PL/Java úgy működik, hogy az eljárásokat java-ban mint statikus metódusokat írjuk meg, majd ezeket rendeljük hozzá az eseményekhez. Sajnos a dolog nem ennyire egyszerű, nekem legalább 6 órámba telt mindennel együtt, amíg ubuntun beállítottam egy hello world szintű triggert.