Nyílt levélben kéri az EU-tól a Sun-Oracle üzlet elfogadását a MySQL volt vezetője

Oracle

"Nyílt levelet intézett az Európai Bizottság versenyügyi főbiztosához Marten Mickos. A MySQL korábbi vezetője azt állítja, a Sun és az Oracle összeolvadása nem hátráltatja, hanem elősegíti a versenyt a relációs adatbázisok piacán és az akvizíció késleltetése káros a felekre nézve." A részletek itt. Marten levele elolvasható itt.

( dejo v | 2009. 10. 10., szo – 16:19 )

Az nem lenne jó, ha a SUN tönkre menne, javai értékei elenyésznének.
Ez a felvásárlás, a SUN értékeit, -legalább annak egy részét-, megmentheti.
Azt, hogy ebben mennyi a versenypiaci kockázat én nem tudom felmérni.
Hogy a felvásárlás hiányában mi lenne a SUN sorsa szintén nem tudom. Valószínűleg veszítene az értékéből és megvenné valaki más, aki vagy hasznosítaná a benne lévő értékeket, vagy megszüntetné, hogy egy szereplővel kevesebb legyen a piacon. Mindenesetre a SUN által megnyitott szabad licencek alatt kiadott kódok, jelentős biztonságot nyújtanak azok felhasználóinak.
--
не закурить! (Ne gyújts rá!) не куриться! (Ne dohányozz! Ne füstölögj!)

"Ez a felvásárlás, a SUN értékeit, -legalább annak egy részét-, megmentheti."

Az írásod analogonjára tulajdonképpen ugyanígy indokolható az, hogy milyen nagyszerű is az, ha az ember az orrán nem kap levegőt, akkor késsel jó nagy lyukakat vagdos rá a mellkasára a sok rosszarcú levegővételét megkönnyítendő, közben meg hogy ne terhelődjön túl, a rolexet meg a tárcát határozatlan időre megőrzésre átveszik... píárduma, kapitális baromság... Az oracle piacot vásárolt, és közben megsemmisítette a legnagyobb konkurrenciáját, közben meg elsorvasztja a kapcsolt termékeit (persze miután lejárt a kötelező supportszerződések garmadája)

oracle, My Ass Cue L, postgres, és a többi hasonló játéxer... hogyan tovább?

Az oracle is egy tetű egysejtű, mind a nagyok 99%-a; mindenféle bevett trükkel és bloatware kőlevesekkel, vizelet minőségű supporttal, hemzsegő ózonlik nagyságú biztonsági rések eltitkolásával és srófolt teljesítménymutatókkal tupírozza fel a saját termékeit, ezáltal a zsebét...

100% community-ellenes.

idevág, hogy a gugli meg úgyis forkolni fog egy jó mysql brancsot, és viszi tovább, de sajnos még jó néhány SunOs-dolog van, amit nem kéne elsorvasztani (mert jelenleg ez a tendencia).

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

Ejha kedves "strangelove", hát te aztán tényleg nagy közösség-rajongó lehetsz - vagy mi a szösz! Azt írtad, hogy: "Az oracle piacot vásárolt, és közben megsemmisítette a legnagyobb konkurrenciáját..." Mit tehet a magamfajta, kevésbé közösség-rajongó pára, csak ámul és bámul ennyi érzelem láttán.

Amikor a mindennapos rajongásod közepette ez a fenti gondolat szikrája kipattant az elmédből (melyet a szomszéd észlelvén, bizonyára a helyi tűzoltókat tárcsázta), akkor én csak remélni tudom, hogy a "piac" szó leírásakor NEM a MySQL piacára gondoltál.

No, de ha mégis, akkor kérlek engedd meg, hogy a szíves figyelmedbe ajánljam az erre vonatkozó felmérési eredményeket. Néhány százaléknyi eltéréssel (ami attól függ, hogy melyik cég végezte a felmérést, milyen módszerrel és mikor), nagyságrendileg ez itten a valós helyzet:

- Oracle: 44,3%
- IBM (DB2): 21 %
- Microsoft (SQL Server): 18,5%
- Sybase: 3,5%
- Teradata: 3,3%
- MySQL: 0,2%
- Stb.

Drága HUP-portáltársam, pusztán csak a móka és kacagás kedvéért kukkants rá az utolsós sorra. Igen, igen... oda, ahol a büszke MySQL adatait láthatod.

A számokat átfutva megfigyelhető, hogy a nevezett MySQL "tényező" piaca olyan kicsi, hogyha a Hubble űrteleszkópot ráirányítanánk, akkor a háttérben szorgoskodó tudósok nyugodtan hátradőlnének mondván, hogy: "Nincs itt kérem semmit, csak a nagy, fekete sötétség."

Piacról ennyi elég.

Részelek
">itt és itt.

Köszönöm a figyelmet.

Jó munkát, jó egészséget!

Üdv,
PutAbout

Ui.: Ami pedig magát az Oracle adatbázis-kezelőt illeti, 15 éves fejlesztői tapasztalatom alapján a személyes véleményem az, hogy toronymagasan a legjobb mind funkcionalitásban, mind teljesítményben, mind pedig a megbízhatóságát tekintve.

Költségcsökkentés céljából lecseréljék MySQL-re az Oracle-t?

A MySQL az nem egy játékszer?
Tudomásom szerint "igazi" üzleti alkalmazásokat nem MySQL-re írnak.

Vagy mióta nem csak PHP-s alkalmazásokhoz lekérdezéstámogatásra lehet használni, azóta "hirtelen" minden adatbázis-kezelő alkalmazást fejlesztő cég rákapott a MySQL-re, aki az 5-ös, ismét leírom, az 5-ös verziótól kezdve nyújtja a tárolteljárásokat, triggereket?

Ez vicc, ugye?!

Gondoljatok máá bele! Egy cég egészen az 5-ös verzióig nem is adatbázis-kezelőt gyártott, aztán meg "hirtelen" kiadot egy verziót, amivel végre adatbázis-kezelést is lehet csinálni.

Most komolyan, melyik cég agyalog azon, hogy egy kiforrott (Oracle, DB2, SQL Server) után nekiálljon "szórakozni" egy kezdetleges játékszerrel.

Ja, mert a MySQL ingyé van. Hát az Oracle, DB2, SQL Server is van inygé, igaz, hogy korlátozott e verziók képessége, de olyan korlátok ezek, amelyik kisebb cégeknek nem nagyon korlátok. Akik meg nagyobbak, azok azért nagyobbak, mert ..., és ennél fogva nem bíznák rá az üzleti kritikus adataikat egy olyan adatbázis-kezelőre, ami most tanulja implementálni a tárolteljárásokat, triggereket.

Szóval maradjunk annyiban, hogy egyelőre a MySQL nem versenytársa az teljes értékű adatbázis-kezelőknek PONT.

"Mert az app is csinálhatja", meg ahogyan Móriczka elképzeli, úgy is működhet egy rencer.

Kultúrkörökben az adatkezelés az adatbázis-oldalon hajtódik végre tárolteljárásokkal/triggerek.

Amikor kliensoldalon adatkezelnek az "alkalmazások", így idéző jelek közé zárva, az a halálom.
Mórickaprogramozók mócceresen átrángatnak adatokat a kábeleken, mert általában nem értenek az adatbáziskezelő-alkalmazások technológiájához, és amúgy is mindenki tud programozni, a hülye júzer meg amúgy sem lát semmit a szarul megírt alkalmazásbó, mert nekki elég ha elhiszi, hogy Mercibe ült bele, az, hogy egy szar trabant ketyeg alatta nem fogja megtudni soha.

De hagyjuk, mert a piacvezető bérszámfejtőprogramoló Nexon sem nőtt még fel odáig, hogy elhajtsa a Clipperen nevelkedett programolóit, és vállalati adatbázis-környezetben nevelkedet programozókkal írassa át a tetves programját.
És ez sajnos nem vicc. A Microsoft 2005-ben büszkén mutatta be őket, mint Microsoft-partnert, mert hogy most már a "Bérenc" is SQL Serverrel van "megtámogatva", csak arról felejtettek el akkor szólni, hogy egyetlen tárolteljárást sem írtak bele a csúcsszuper új Nexon bérprogramba!!!

Azoknak, akik nem értenek ehhez, megemlítem, hogy a Bexon kliensoldali adatkezelést végez, az SQL Servert csak arra használja, hogy SELECT, UPDATE meg DELETE, oszt pont.

Ennek meg az az eredménye, hogy egy eccerű lekérdezéskor minden, ismétlem minden adat átmászik a kábelen a klienshez az adatbázis-szerverről, oszt mindenki csodálkozik nagyokat, hogy az átlagos lekérdezések miért tartanak 15-30-50 percig.
A "hozzáértő" rencergazda-üzemeltető meg ilyenkor megálmodik egy nagyobb vasat még tőbb memóriával, ,ert az majd biztosan sokat fog segíteni a válaszidők csökkentésén.

Emlékszek én még arra, amikor a úgy javítottak clipperes alkalmazásokon, hogy SWITCHre cserélték a HUBokat... pedig a clipperes szarokat kellett volna lecserélni valódi adatbázis-kezelő alkalmazásokra, amik pl. tárolteljárással dolgoztak volna.

Aranyszabálynak: kliensoldal megjelenít, nem kezel adatokat, arra szerveroldal vagy köztesréteg való.

Ismerem a problémát. Emiatt dobtam a linuxos megoldásomat és írtam sajátot. Egyszerűen lehalt a lekérdezésbe az app. SQL másfél megát küldött ki egy számla nyomtatási képéhez.

Ettől függetlenül állítom, hogy tárolt eljárás nélkül is meg lehet írni úgy az appot, hogy minimális lesz a forgalom. Na oké, azért nagyobb, mint egy tárolt eljárásé, de ez elkerülhetetlen.

Jó, egy dolgot elfelejtettem mondani: én itt nagyon új vagyok, izé nem csak a listán, hanem a linuxos világban is, és azt sem tudom, hogy pontosan mióta van Oracle-ös és DB2-es ingyenes adatbázis-kezelő. Talán 2004 körül jött ki az Oracle az ingyenes verzióval, oszt rá egy évre az IBM? Nem tudom, majd valaki megírja a pontos dátumot, de abban biztos vagyok, hogy 2-3 éve biztosan van, tehát 2-3 éve MySQL kutyavaszt használni rendes alkalmazás alatt bénaság, rövidlátóság, stb.

Microsoft világában már 1998-óta van, tehát aki Windowsra fejleszt 1998-óta adatbáziskezelő-alkalmazást, és nem használt a kezdetek óta tárolteljárásokat, triggereket, az nem hozzáértő fejlesztő, amennyiben az ingyenes adatbázis-kezelő, mint opció számít.
Ha nem, akkor meg nincs miről beszélni, ott vannak az "igazi" adatbázis-kezelők, és aki nem ezeket használja, hanem bohóczkodik mindenféle vackokkal, akkor az szatócsboltoknak való fejlesztő.

Nem akarok megsérteni ám senkit, csak úgy gondolom, hogy ha az ügyfél hajlandó megvásárolni az alkalmazás használatához egy igazi, étsd Oracle, DB2, SQL Server Sybase adatbázis-kezelőt, és a fejlesztő meg valami vacakra írja meg az adatbázis-kezelő alkamazést, akkor az nem fejlesztő.

De javítsatok ki, ha tévedek: azért a nem Microsoftos világban is régóta elérhetők ingyenes adatbázis-kezelők, olyanok, amelyekben van tárolteljárás és trigger.

A MySQL azért terjed el tudomásom szerint ilyen mértékben, mert a Webszerveres alkalmazásokra optimalizálták, azaz elég volt, ha lekérdezni lehetett vele, mert igazi adatbázis-kezelésre nem volt igazán szükség. Ezért is nem volt az 5-ös verzió előtt semmi olyan tulajdonsága, ami egy "igazi" adatbázis-kezelő sajátja volt már 1988 óta.

"itt nagyon új vagyok, izé nem csak a listán..."
Én is új vagyok a listán, ebből fakadóan szerintem mondhatom sértés nélküli jó tanácsként, hogy "picit szerényebben".

Pár korábbi gondolatoddal részben egyetértek. Tapasztalataim alapján:

1. Nagy adatmennyiség egybeni viszonylag egyszerű feldolgozására tárolt eljárásokat célszerű használni.
2. Akár csak kicsit is bonyolultabb feldolgozási feladatokat sokkal jobb a köztesrétegben elvégezni.
3. Kliens oldalra én is csak mutatóba küldenék adatot.

Ingyenes adatbázis kezelőket nem csak olcsójánosok használnak. Legfőbb gond pl. az Oracle-el az szokott lenni, hogy baromi magas az egyedi felhasználónkénti licensz ára, amit nem csak az egyidejű adatbázis kapcsolatokkal mérnek, hanem a teljes rendszer szintjén valamennyi végfelhasználóval. Ha pedig limit nélküli felhasználóra indítasz egy üzleti projektet (pl. website) akkor ugye a szerver erőforrásokkal mérik az árat.

A MySql-t egyébként én sem favorizálom, nem is igazán ismerem. Mi inkább PostgreSQL-t használunk.

A szerénységgel egyetértek.
Elnézést, ha szerénytelennek tűntem volna, viszont ami a szívemen, az a számon, legföljebb majd jól beszólnak.

Köztes rétegben történő feldolgozás általában inkább emberi paraméterek miatt szokott történni, más tényező akkor elfogadható, ha nem lehet az adatbázis-kezelő szintjén a feldolgozás közbeni tevékenységet elvégezni.

Emberi tényező pedig az, hogy a köztesréteget a programozó a kliensoldali fejlesztéshez használt nyelven tudja programozni, azaz nem kell neki "vesződnie" az adatbázis-kezelő saját nyelvével, amit sajnos a legtöbb adatbáziskezelő-alkalmazást készítő programozó nem ismer olyan szinten, hogy megfelelő minőségű tárolteljárást tudjon létrehozni.
És itt nem csak a szintaxist kell megtanulni, hanem az adatbázis-kezelő működését is. Az ilyen ismeretek hiányában vagy hibásan működik majd a rendszer, vagy teljesítményproblémák fognak jelentkezni, és ilynekor jönnek az "okos" megjegyzések, hogy kliensoldali feldolgozás jobb teljesítményt ad, mint a tárolteljárással megírt...

Persze időközben már SQL Servert is lehet programozni .NET nyelveken, azaz lehet írni tárolteljárást pl. C#-ban, és ha jól tudom, akkor Oracle-ön is lehet Javaban programozni tárolteljárást. A baj csak az, most ismétlem magam, hogy az adatbázis-kezelőt is alaposan meg kell tanulni, hogy rendse tárolteljárások készüljenek. (Azért azt is meg kell említeni, hogy azért teljesítményben alatta van a natív tárolteljárásnak egy C#-ban megírt, és nyilván a jávás is.)

Többnyire ezért szoktak inkább köztesréteget programozni.
A skálázhatóság egy másik indok lehet még.

"Többnyire ezért szoktak inkább köztesréteget programozni.
A skálázhatóság egy másik indok lehet még."

Én a skálázhatóságot gyakoribb indoknak látom, mint az emberit, de tudja fene. Azt akkor elismered, hogy ha a CPU terhelést leszedjük a DB-ről az úgymond köztesrétegbe (egyáltalán ez mihez képest köztes ugye?), akkor jobb lesz a DB-nek is? :)

Szerintem még nem láttál tisztességes alkalmazást tárolt eljárás nélkül. Szerintem elég sok ember van így. Szerintem elég sok ember van másképpen is, méghozzá úgy, hogy látott tisztességes alkalmazást tárolt eljárás nélkül. Ezeket a nagybetűs pontokat meg az abszolútikus kijelentéseket szerintem felejtsd el mert nem vesznek komolyan...

Tisztességes alkalmazást már kláttam, de adatbázis-kezelő tisztességes alkalmazást tárolteljárások nélkül még nem.

Ugye egyről beszélünk, és nem a személyi adatkezelő alkalmazásokról, amelyek egyetlen személyt szolgálnak, ki egyetlen számítógépen futtatva.

Adatbázisokat viszont általában nem egy embernek "építenek", így technológiailag helytelen a kliensoldalra adatbázis-kezelést vagy akár adatkezelést rakni.

Persze, valamikor a dBASE is korszerű eszköz volt PC-s környezetben, de az valamikor volt, amióta viszont korszerűbb technológiák állnak rendelkezésre, a régebbi technológiák korszerűtlenekké váltak, erkölcsileg 0-ra avultak.

"Erkölcsileg" pedig az én szememben is alacsony szinten állnak azok, akik a korszerű technológiák megléte mellett korszerűtlen technológiákat alkalmaznak.

Az a baj, hogy nem ennyire fekete vagy fehér a kérdés, hanem szürke, és azon belül is mindenféle. Van, amikor jó a tárolt eljárás használata, van, amikor nem.
Például egyszer kerestem postgresql-hez rendes clusterező megoldást, nem találtam olyat, ami minden tárolt eljárást normálisan lekezelt volna. Tárolt eljárás nélküli verziót azért lehet találni.

Van egy olyan érzésem, h a "korszerű technológia" kifejezést sokkal inkább a populáris szinonimájaként használják. A "korszerűségre" hivatkozva sokan hajlamosak elfelejteni, egy ilyen technológia még nem lesz automatikusan minden helyzetben az adott célra megfelelő.

azert nem kicsit vagy elszallva. Igy csipobol leszolni mindenkit nem biztos hogy kene, csak egy tanacs. Talan a szakmai ertekeiden kivul helyezhetnel csak egy picit nagyobb hangsulyt az emberi ertekeidre is (szinten csak egy tanacs).

Amiket mondasz az valoban szep es jo, amolyan tankonyvi filozofia. Elemeletben remekul hangzik, sajnos az emlelet es a gyakorlat kozott legtobbszor nagy kulonbsegek vannak.
Peldaul nem mindig van valasztas. Minel nagyobb ceghez veszik fel az embert annal valoszinubb hogy azzal kell dolgozni ami van, ha pedig netan olyan pozicioba vesznek fel eleve hogy tudsz ezen valtoztatni, akkor meg minel nagyobb ez a ceg ez valoszinuleg annal lassabban fog menni. Az is elofordulhat hogy mar nem is lennel ott mire esetleg befejezodne...
Ha nem ilyen a helyzet es megvan a lehetoseg hogy olyan eszkozoket hasznaljon az ember amit o szeretne, akkor pedig meg mindig fenntartom a "feladathoz celeszkozt" elvet. Egy csomo mindenhez agyuval verebre az Oracle (igen, van amihez kell, ahhoz az is valo, de azt mondani altalanossagban hogy mindenhez Oracle az kicsit elvakult dolog), az ilyenekhez altalaban tokeletesen megfelel egy my, vagy egy pg, kinek melyik. Ha a te velemenyed szerint ettol valaki szakmailag 0, akkor ezt en is gondolhatnam azokrol, akik miatt a kis picsanyi cegek telephelyen 4 procis brand servereket talalok amiken semmi mas, csak egy postfix fut, es napi 10 level forgalmat bonyolit (de arra kellett a millios server - agyuval verebre szinten).

"Amiket mondasz az valoban szep es jo, amolyan tankonyvi filozofia. Elemeletben remekul hangzik, sajnos az emlelet es a gyakorlat kozott legtobbszor nagy kulonbsegek vannak."

Én még technológiailag is tudnék vitázni azzal a meglehetősen erős állítással, hogy "minden adatfeldolgozást tárolt eljárásba". Azzal egyetértek, hogy amennyire lehet legközelebb az adatbázishoz, de az én filozófiám szerint is inkább a feladathoz válasszuk az eszközt és ne ökölszabályok és mantrák mentén tervezzünk.

A tárolt eljárásolások ellen több érvem is van:
1. Egyből adatbázis gyártó függő lesz a rendszered. Ez nem mindenhol baj, de van ahol nagyon is az.
2. Nem minden feladat végezhető el tárolt eljárásként. A világ nem csak SELECT-ekből és UPDATE-ekből áll.
3. Cluster, cloud computing, stb. (fentebb már említette valaki)

Ezek világos érvek, és igazad is van.

De még mindig azt mondom, hogy nem ezért szoktak "sokan" nem tárolteljárásban gondolkodni, hanem az emberi tényező miatt.

Ha egy rendszer teljesítménye és megbízhatósága fontos, és a feladat elvégezhető, ahogy írod, db-oldalon, akkor a tárolteljárást fognak használni.

Az persze más kérdés, ha a megrendelő sem tudja, hogy neki milyen technológiára van szüksége és a fejlesztő sem tudja, hogy adott helyre mit illik lerakni...
Azt a tényt ugyanis el kell fogadni, hogy boldog-boldogtalan ír adatbázis-kezelő alkalmazásokat. Ilyeen világban élünk, oszt kész.

De ettől még lehet valakinek az a véleménye, hogy a jelenleg működő adatbázis-kezelő alkamazások zöme hulladék. Igen, ez erős kifejezés, meg nem is nagyon álja meg a helyét mindenki felfogásában, de azt akarom kifejezni, hogy a TRABANT az egy hulladékautó, és persze, hogy a boldog Trabanttulajdonosok az ilyen véleményeken jól kiakadnak és megsértődnek, de ettől még a Trabant az egy hulladék, ha azt nézzük, hogy 2009. októbert írunk.

"De még mindig azt mondom, hogy nem ezért szoktak "sokan" nem tárolteljárásban gondolkodni, hanem az emberi tényező miatt."

Utálni fogsz érte, de akkoris megfordítom: "sokan" azért használnak tárolt eljárást, mert nem értenek máshoz (úgymond "emberi tényező". Rengeteg ilyen tapasztaltom van.

"Ha egy rendszer teljesítménye és megbízhatósága fontos, és a feladat elvégezhető, ahogy írod, db-oldalon, akkor a tárolteljárást fognak használni."

Meglepő, de ez sok rendszerben kifejezetten hátrány lenne. A teljesítményből és a megbízhatóságból az egyiket ki lehet választani és az eldönti. Ha DB-ben csinálod, akkor tuti megbízhatóbb lesz, ha távol, akkor többnyire jobban teljesít. Persze borzasztóan kérdéses az IO/CPU arány, úgyhogy ebbe gondolj bele, mielőtt újra és újra ilyen abszolutikus kijelentést teszel.

Kultúrkörökben az adatkezelés az adatbázis-oldalon hajtódik végre tárolteljárásokkal/triggerek.
Amikor kliensoldalon adatkezelnek az "alkalmazások", így idéző jelek közé zárva, az a halálom.

Én láttam már tárolt eljárásból dinamikus HTML-t kiszolgálni. Szerintem meg az a nagyhalál...

Mórickaprogramozók mócceresen átrángatnak adatokat a kábeleken, mert általában nem értenek az adatbáziskezelő-alkalmazások technológiájához

Mórickaprogramozók mócceresen betolnak mindent tárolt eljárásba, mert általában nem értenek az adatbáziskezelő-alkalmazások technológiájához...

Hehe. Jó vicceid vannak a tisztán nem látásról, veszek is rögtön egy szemüveget :)

Én elhiszem hogy markáns véleményed van, de hogy ennyire nyilvánvalóan ignorálod mások saját tapasztalásait és véleményüket, az félelmetes, és túl sok további szószaporítást nem is érdemel.

Tarolt eljerasokkal alkalmankent picit jobb teljesitmenyt lehet elerni, de ennek ara van:
- Mivel nincs tiszteseges absztrakcios reteg hozza (FIXME), igy minden DBMS -hez kulon kell megirni, vagy hozza lancolod magad egyhez
- Bonyolultabb lesz az upgrade folyamat, nehezebben atlathato/kovetheto a kod, konyebben labon loheted magad, a legkevesebe az hianyzik, hogy mindenfele kokler tarolt elrarasozzon es nekem kelljen megmondani hol baszodik el a rendszer. Egy nagy rendszert eleg nehezkesen lehet atlatni, ha mindenfel csodas triggerel van megtuzdelve, konyen nem vart jelenseget produkalhat egy uj feature hozzaadasa, vagy valami artatlanak tuno DB management lepes.

Nehogy azt hidd, hogy a modern hu de enterspajz termekek teli vannak ilyenekkel, kurvara nem. Supportnak legkevesbe az hianyzik, hogy a magukat labon lott vasarlok nyavajgasat kelljen hallgatni.

Abban igazad van, hogy gyakran nem leg coolabb megoldast valasztjak a nepek, mert nincs 500 lvl80-as programozo a kozelben, ebben kepben tarolt eljarasok csak egy aprosag.
Ill. a vasarlo (legyen az kulso vagy belso), kurvara nem tudja mik az igenyei, ill. mik lesznek azok. Valoszinuleg nem tarolt eljarasokkal tudod legkonyebben kovetni az igenyeket...

Ami teljesitmenyt illeti, manapsag nagyon szarul kell kodolnod ahhoz, hogy lassu legyen valami egy uzleti megoldasban, ezert (is) lehet raklapnyni penzert eladni, uber fos, igenytelen, atgondolatlan alkalmazasokat,

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Erről most eszembe jutott egy 3 évvel ezelőtti munkám, ahol az volt a feladat, hogy brutális mennyiségű (600-800) tárolt eljáráshoz képest meg kellett mondani, hogy néhány táblának néhány oszlopának a módosítása hány tárolt eljárás átírását (tesztelését, kapcsolódó programok tesztelését) vonná maga után.

Én akkor egy hét alatt írtam egy SQL query parsert (ami csak a felsorolt proc-okat parsolta, de elég brutál volt), utána egy data flow analyzert (hogy melyik érték hol van írva, hol van olvasva), de ilyent soha többet nem akarnék sem írni, sem látni.

A trigger nem azé lett kitalálva, mert épp vót még egy kis hely Józsibácsi szerszámos ládikójában.

Meg nagyon nem azé lett kitalálva, hogy lábon tudják magukat lőni a "töketlen" adatbázis-fejlesztők.

Azé lett kitalálva mert muszáj vót kitalálni, és a Sybase meg "jókitalálta", de annyira, hogy bekerült minden "felnőtt" adatbázis-kezelőbe, mert nem mindenho számlázóprogram-csodákat vagy webáruházcsodákat gyártanak.

Wan "ahol" az adatbázis konzisztenciája számít, és ehhez meg kell eszközt adni az adatbázis-programozó kezébe.

Arról meg nem vitatkozzunk, már, hogy Józsi-Pista nagyot gondol magáró, oszt nekiáll mától trigereket programolni, mert az olyan trendi.

A mai MVC világban nem igazán tesz jót az átláthatóság és karbantarthatóság szempontjából, ha a Controller rétegbe való dolgok benne csücsülnek a triggerekben.

Az én véleményem az, hogy triggert és tárolt eljárást alkalmazni kb. olyan, mint goto-t írni egy C++ programba. Nagyon-nagyon ritkán van rá szükség, de akkor tényleg sokat gyorsíthat vagy egyszerűsíthet.

10 éve még én is használtam rendesen tárolt eljárásokat és triggereket, de az utóbbi időben a szakma legnagyobb részével együtt én is áttértem MVC használatára és nem rakok logikát az adatbázisba, csak kifejezetten ihdokolt esetben, ami nagyon ritka.

Az én tapasztalatom az, hogy egy tipikus félórát futó query-t tárolt eljárásba téve lehet spórolni 1-2 másodpercet. Rendesen átírva viszont sokszor 1-2 másodpercre csökken a futási idő akkor is, ha kliens-oldalon megy.

A másik, hogy már rég elmúlt az a világ, ahol megtervezték az alkalmazást megírták, aztán ment évtizedekig. Manapság inkább az lett fontos, hogy egy alkalmazást könnyen lehessen módosítani, fejleszteni. Triggerekbe szétszórt logikával ilyet nem lehet csinálni.

Mondom, hogy nem tudod, hogy a trigger mire lett kitalálva.
Semmi köze az alkalmazás-logikához.

Azt meg nem hiszem el, hogy egy órákig futó "tipikus" lekérdezésnél pár másodperccel gyorsabb egy azonos lekérdezés tárolteljárásban. Már eleve a tipukust jó lenne tisztázni, de maradjunk inkább a triggernél, mert azzal vannak téves fogalmaid.

Nekem úgy tűnik, hogy Zsolt-nak írtam, hogy nem tudja, hogy mire való, nem pedig mindenkinek.
Mindegy.

A triggert azért találták ki, mert vannak olyan "megszorítások", amelyeket nem lehet az adatbáziskezelő "nyelvén" megfogalmazni.

Entitásintegritást többnyire elsődleges kulcsokkal kell kikényszeríteni,
referenciális integritást idegenkulccsal,
tartományintegritást meg CHECK constrainttel.

Azonban egy tartományintegritást-kikényszerítést nem mindig lehet CHECK-kel kivitelezni, pl. ilyenkor kell triggert alkalmazni. Mivel a trigger tárolteljárás (tehát bent lakik az adatbázisban, elválaszthatatlan részét képezve annak), és az adatbáziskezelő futtatja, ezért ellentétben a köztesrétegbeli üzleti logikával, amit nagyon nem az adatbáziskezelő futtat, ezért a trigger mindig működik. (Hagyjuk azt, hogy ki-be lehet kapcsolni, ha kérhetem, jóóó:)

Ha pl. a tartományintegritás-kikényszerítés az adatbázis része, akkor az az adatbázis része, és mindig működik. A köztesrétegbeli üzleti logika nem része az adatbázisnak, így az integritás megőrzése köztesrétegbeli kóddal elég nagy kihívás.

Integritás-kikényszerítés akkor működik megbízhatóan, ha a legközelebb van az adatbázishoz.
Az adatbásisbannál nincs közölebb... :)

Az üzleti logikát meg nem azért szokták kiemelni, tehát elválasztani az adatbázistól, mert azt úgy szép, vagy jó. Ez hülyeség.

Pont az a baj a köztesréteggel, hogy nem része az adatázisnak. Pusztán kényszerűségből van 3. 4. n. réteg, nem azé mert valmi akadémikus "művészileg" így tartja jónak. Teljesítményproblémák (skálázhatóság), meg fejlesztési költségcsökkentésből találták ki a köztesréteget.
Az _adatbázis_ minőségének szempontjából viszont minőségromlás.

Gondolj bele: lementesz egy adatbázist. Mint mentes el ilyenkor? Az adatbázist. És amikor visszatöltöd 1 év múlva az adatbázist, akkor mit fogsz csinálni? Az alkalmazásod szana szét van dobálva köztes rétegekre! Az adatbázis önmagában nem sokat fog érni.

Ha azonban az adatbázisban van az üzleti logika, akkor az adatbázismentés visszatöltésével mindent helyreállítottál, már csak a megjelenítési réteget kell a felhasználó gépére varázsolnod.

Abban tehát biztos lehetsz, hogy nem az x. verziójú adatbázis, y verziójú 3. réteggel és egy z verziójú 4. réteggel lesz összepárosítva.

Ha meg tudod jeleníteni az adatot, akkor az minőségi adat, nincs egy közbenső réregben eltorzítva az által, hogy "véletenül" nem jó köztesréteg-mentést állítottál vissza.

Egy szónak is száz a vége! :)
Afatbázsi-kezelő alkalmazások akkor igazán jók, ha minden benne lakik az adatbázisban. Igen, tárolteljárásokban a kódok, a megszorítások elsődleges- és idegenkulcsokkal, checkkekel, és triggerekkel.
Az ügyféloldal meg csak megjelenít.

Ez tényleg a századik végem! :)

benne van

Egyrészt már kiosztottál ebben a fórumban mindenkit, és mindenki tudja, hogy itt csak TE értesz igazán az adatbázisokhoz. Az hogy most speciel Zsoltot osztottad ki, teljesen mindegy.

Aztán azt írod, hogy "Mondom, hogy nem tudod, hogy a trigger mire lett kitalálva. Semmi köze az alkalmazás-logikához."

Nem tekintem a wikipediát perdöntőnek, de az itt felsoroltak nagy része mégiscsak az alkalmazáslogikához kapcsolódik:
http://en.wikipedia.org/wiki/Database_trigger#The_need_and_the_usage

Továbbmegyek, szerintem az általad felsorolt integritások szintén az alkalmazáslogika részei.

És az, hogy régen _kizárólag_ az adatbázist ismerték, mint hely, ahol ezt vizsgálni lehet (lévén hogy a kliens közvetlenül küldte az adatot és nem lehetett megbízni benne), az nem jelenti azt, hogy most is csak ez van. Architekturális döntés, hogy bizonyos számításokat a 3., 4., sokadik köztes rétegben végezzünk, mert esetleg más a karakterisztikája, jobban belefér az adott CPU/IO egyensúlyba, vagy csak az évek múlásával karbantarthatóbb. És bármilyen furcsa, sok helyen lényegesen jobb is így.

De hogy mondjak egy megrökönyítő dolgot: sokan arra használják az adatbázis triggert, hogy az adatváltozásról eseményt generáljanak. Hoopppá, biztosan nem erre találták ki :P

Nyilván a Zsolt "Triggerekbe szétszórt logikával" mondatát reagáltam egy kicsit túl.

Én nem a Wikipédiát nézegetem, -bocs, hogy most sem vettem rá a fáradságot- amikor "kitaláltam" hogy mire való a trigger.

Szelektív olvasás meg király!

Az utolsó mondatodon meg tényleg megrökönyödtem.
Meg van még DLL trigger, logon trigger, és ezek nem DML triggerek.

Mindegy!

FYI: Kerultek mar be triggerek adatbazisba, mert en azt modntam, hogy az jo, es abban helyzetben legegyszerubb megoldas volt az integritas megorzosere, tudomasom szerint nem lett megbanva. (relative, kicsi rendszerrol volt szo)
Tudok en triggerek mellett is beszelni :), De alltalanos szabalyt megfogalmazni, hogy mikor es mit szabad csainalni az eleg nehez feladat.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Láttam már olyan céget, ahol azért nem az olcsóbb (open source, ingyenes) terméket választották, mert ha most spórolnak valamennyit a budget-en, akkor jövőre eleve kisebb keretet kapnak, és ha kisebb a keret, kevésbé számítanak komolynak a manager kollégák között. Ettől még igazad van neked is, én csak erre céloztam.

De hát pont az a lényeg, hogy inygyen sem kell rosszabb termékre cserélni; ott vannak a teljes értékű adatbázis-kezelők ingyenes verziói.

Akkor meg hogy jön a képbe egy ingyenes félkegyelmű adatbázis-kezelő egy ingyenes teljes értékűvel szemben?

Ja, ha valakinek a 4GB-os adatbázisonkénti méret nem elég, vagy egyéb teljesítményproblémákkal küzd, és az 1GB-os RAM és az 1 processzor korlátokat jelent az ingyenes SQL Servernél, akkor az is félkegyelmű, ha ilyen igények esetén ingyen akarja megoldani a problémáját. Akkor annak ugy kell, és használjon MySQL-t ingyen, korlátok nélkül.

"akkor az is félkegyelmű, ha ilyen igények esetén ingyen akarja megoldani a problémáját"

Ha végignézed az elmúlt évek "nagy durranás" weboldalait (másképpen hívják őket web 2.0-nek vagy 3.0-nak is), akkor melyik a gyakoribb? Oracle RAC, vagy valami ingyenes, open source? :)

Gyakoriság alapján minőségi következtetéseket nem nagyon lehet levonni.

Valamikor, és sajnos még egy kicsit mai is, a Clipper-programozók hazája voltunk.
Szinte minden ügyviteli alkalmazást clipperes programolók követtek el

Akkor most a Clipperrel elő lehetett állítani minőségi cuccot. Ugyan.
De ez láthatóan nem sok mindenkit zavart, mert a felhasználók tömegével clipperes alkalmazásokat futtatak.

Ja, programolni mindenki tud kis hazánkban, a Clippert meg nem atomfizikusoknak találták ki.

Most persze lehet, hogy sok (idősebb) volt clipperes megsértődik, de ettől még a Clipper egy határ kaki (technológiailag). Az amit a clipper adatbázis-kezelés révén csinál, már akkor elavult volt, amikor kijöttek vele. Na jó, 1987-ben még nem ott tartott az adatbázis-kezelés a PC-piacon, mint a '90-es évek elején, de végigprogramozni a 90-es éveket, plusz még egy kicsit a 2000 utáni éveket durva, amikor volt rendes adatbázis-kezelő DOS-ra már a 90 évek előtt is.

Ez véleményem szerint az igénytelenség és a hozzá nem értés keveredése annál a tömegnél, akik ezt használták.

A legjobban pedig az teccik az ilyen programokban, hogy kiszúrták a szemit a szerencsétlen felhasználónak egy INDEXELÉS menüponttal, mondván, ha valami gond van, akkor futtassák le, oszt majd gatyábarázódik az adatbázis. Ez tényleg vicc.

Fel kellene már nőni sok programozónak, akik ügyviteli programokat csinálnak, hogy az adatbázis-kezelés az egy komoly terület, és nem holmi szutykokkal kell szórakozni adatbázis-kezelés címszó alatt.

De nincsenek afelől, hogy mindig is túlnyomó többségében az igénytelen technológiájú alkalmazásokból lesz több, mert programozni mindenki tud, az informatika meg az a tudomáyn, amihez ma már mindenki ért.

"De nincsenek afelől, hogy mindig is túlnyomó többségében az igénytelen technológiájú alkalmazásokból lesz több, mert programozni mindenki tud, az informatika meg az a tudomáyn, amihez ma már mindenki ért."

Áááá dehogy! Csak Te! :)

ps.: azt hiszem vehemenciád és rengeteg szabadidőd a kompetenciádat kérdőjelezi meg :)

Persze nyilván átment a mondanivaló, csak hát nem kell mindent mindig megérteni; hogy gyarapodna akkor egy ilyen fórum hozzászólásokkal?

Ui.
Akkor itt csak fejlesztők vannak, és én vagyok az egyetlen rencergazda, akinek akkora a kompetenciája, hogy minden általa felügyelt rencer szépen magától működik, és ráér itt múlatni a "drága" idejét?
:)))

Van aki nem informatikus, hanem pl CFO egy termeléssel foglalkozó cégnél. Mondjuk ez a valaki amikor még ici-pici volt a cég és Linuxra váltott egy szarul választott ügyvitel miatt elkezdte fejleszteni a saját kis ERP-jét. Sík hülye volt mindenhez, de a LAMP-ot vágta minimum szomszéd pistike szinten. :) Mivel az illető CFO és mondhatjuk rá, hogy jártas a termelés szervezés JIT/VMI rendszerekben ezért úgy érezte, hogy van elég gazdasági kompetenciája megszervezni az általa vezetett céget. Szervezéseit, intézkedéseit pedig a matematika nyelvén is eltudta mondani app-jában. Ez valaki tudja mi a tárolt-eljárás, azt is tudja, hogy mire való és kinek kell. Vagy csak azt gondolja, hogy tudja. :) Szerinte tárolt eljárás olyan készletezéshez kell ahol kritikus, hogy ne menjen mínuszba a készlet. Ettől függetlenül neki, mint CFO-nak kedvence a mínusz készlet, mert a cashflow-t az növeli, szabadságot az nyújt. Természetesen a mínusz készlet csak is a késztermékre vonatkozhat, mivel ez egy termelő cég az alapanyag ellátásra nem.
Mit is jelent a mínusz készlet gazdálkodás náluk?
Kétféle raktár készletet néznek:
- Raktárkészlet jelenlegi (aktuális készlet)
- Raktárkészlet feltételes (jelenlegi +/- változások vagyis események amik a jövőben garantált módon bekövetkeznek)

Na kérem szépen egy ilyen gazdasági modellel lehet negatív raktárkészlettel gazdálkodni, továbbá a raktáron lévő termékeket el lehet adni többször is. Nincs felesleges készlet.
Ehhez pedig kurvára nem kell tárolt eljárás. Üzleti modell kérdése szerintem.

Sőt, javaslom a Clipper "újrahasznosítását", természetesen a jól bevált INDEXELÉS menüponttal megkínálva az "app"-otokat.

Mert akkor az igazi élvezet az "adatbázis", ha a Clipper egy kicsit összekuszája az indexeit. :)))
Ha jól értem, ti meg "kurvára" nem fogjátok magatokat emiatt izgatni. :)))

Egészségetekre váljék!

Olvass vissza:
http://hup.hu/cikkek/20090929/postgresql_tortenelem_sebessegteszt#comme…

A Sunnál azt tanítják, hogy a MySQL technikai oldalról már mindent tud, amit a nagyok.

Az Oracle fejlesztő havertól azt hallottam, hogy rettegve várják a napot, amikor a babkávé-részvények feloldódnak az orákulum határtalan bölcsességében, akkor ugyanis nekik menniük kell. Az Oracle DB-t becsukják, a forráskódot megkavarják kódobfuszkátorral és felhintik SHA sóval, hogy aztán a cég korábbi termékeinek kvintesszenciája egyetlen egy hashben maradjon csak fenn Larry irodájának falán.
És jönnek a MySQL-esek, akik a Maria, izé, Falcon, vagy InnoDB? De lehet, hogy MyISAM (vagy a vele sebességben és megbízhatóságban egyenértékű MEMORY) engine-nel letarolják a világ adatbázispiacát.

A hírek szerint a Sun már fejleszti a snapshotolható, naplózható, nem felejtő memóriát, és már a plakátot is kinyomtatták, amelyeken a MySQL MEMORY engine-nel ötmilliószor gyorsabb, mint az Oracle DB (tudja valaki ők milyen engine-t használnak? :).

suckIT szopás minden nap! FreeBSD: ZFS, vagy UFS a {My,Postgre}SQL alá?

Egy weboldal alatt volt, de rettenetesen lassan működött az egész a perzisztens kapcsolatok hiánya miatt.
Amúgy az alkalmazás egy szimpla adatrögzítő-megjelenítő dolog volt összetett műveletek, számítások nélkül.

Egyébként szerintem, ha az ember érti, hogy egy adatbázis-kezelő hogyan működik, tökéletesen elvan az Oracle plusz szolgáltatásai nélkül is, főleg webes környezetben.

A fordított eset (MySQL->Oracle átállás után hatalmas gyorsulás) meg akkor szokott történni, ha dilettánsok írták a query-ket és az Oracle jobb query analyzere tud rajtuk optimalizálni.

Amúgy meg ezt az egész DB-kérdést szerintem nem nagyon érdemes itt túldimenzionálni. Ami egy ilyen kicsi országban a jellemzően kicsi adat-mennyiségekkel nem megy el akármilyen adatbázis-kezelővel egy átlagos hardveren, ott egyszerűen a programozók voltak dilettánsok.

Kb. itt szűkebb és tágabb környezetemben ez a tendencia (ismertség és felhasználás aránya), postgres, mysql, oracle a triumvirátus (meg egy kis db2, halott: mssql). Most egy dobogós a három leggyakrabban használt sql megoldásból hosszabb távon kiesett, vagy legalábbis bizonytalan lábakon áll, a ráépülő forkokat is magával fogja rántani.

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

( turul16 v | 2009. 10. 10., szo – 18:02 )

Eleg sok fronton okoz ez az egyesules felelmet, bizonytalansagot es dontesi nehezsegeket, nem lehet tudni, hogy melyik dolog lesz temetve, meg egy 3. megoldas valsztasa is biztosabb jovot jelent. Mindekinek jobb lenne, ha minnel hamarabb megtoretenne, es az Oracle meg lep amit lep. (En SUN-os vonalat szeretem tobbnyire)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( bambano | 2009. 10. 10., szo – 18:59 )

Nem értem, miért félnek a mysql fanok ettől. Félni az én meglátásom szerint a bizonytalantól kell, a biztostól nem. A 6-os mysql-t már bedöntötte az oracle, én nem látok semmi bizonytalanságot a mysql jövőjét illetően.

( gabrielakos v | 2009. 10. 12., h – 09:45 )

Na akkor reagalok sok mindenre egyszerre:

- a mysql olyan amilyen (technikailag)
- a Sun opensource projekt supportja a tapasztalatom szerint elég gyenge, nem tudom mennyire fájna a mysql projektnek ha a sun nem lenne
- van más opensource adatbáziskezelő, nem is egy
- sok cég választ opensource adatbázist (mondjuk PostgreSQL-t vagy MySQL-t) Oracle helyett. És nem elsősorban a licenszeken való spórolás miatt.
- lehet valódi supportot venni mindegyik adatbáziskezelőhöz független cégektől
- a support minősége nincs egyenes arányban annak árával
- számunkra egy open source terméket sokkal könnyebb supportolni mint egy closed source-t, ezért annak a supportja nálunk olcsóbb, és általában ugyanez ok miatt "jobb minőségű" is. Pl. egy bugfixet meg tudunk csinálni mondjuk 1 nap alatt, és másnap kint van a usernél, ugyanezt próbáld Oracle-el. Vagy Microsofttal. Vagy bármi mással...

--
Gabriel Akos

Az Oracle bugos. Nagyon.
MySQL bugos. Eléggé.
DB2 bugos. Változó.
Sybase bugos. Alacson.
SQL Server bugos. Nem jellemző.

Eléggé félve állítottam össze a fenti listát, mert úgy tapasztaltam, hogy a linuxos közösségben lévők ingerküszöbét elég könnyű átlépni, ha microsoftos cuccok jó minőségét "hirdeti" akárki.
Tény viszont, hogy adatbázis-kezelők közül a biztonságot tekintve kiemelkedő a SQL Server. Teccik vagy nem egyeseknek, ez van. A slammer óta, azaz 2003 óta meredeken a 0 felé konvergált a biztonsági rések száma.

Ezzel csak azt akarom kifejezni, hogy az, hogy annak hogy open vagy nem open semmi köze a termék minőséghez vagy a szupport minőségéhez. Vannak ilyen meg olyan gyartók/támogatok oszt kész.
Azaz vannak ilyen meg olyan emberek; ezek határozzák meg a minőséget nem az, hogy open zászló alatt vagy nem open zászló alatt masíroznak.