Hlavní navigace

Vonku je PostgreSQL 8.3 RC1

5. 1. 2008

Sdílet

Vydanie PostgreSQL 8.3 postúpilo do ďalšej fáze. Vyšla totiž RC1, ktorá už nebude prinášať žiadne novinky, len bugfixy. Na domovskej stránke zatiaľ o nej nie je nie je zmienka, na mirroroch už ju však nájdete.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 5. 1. 2008 23:04

    LO (neregistrovaný)
    Vazeni uzivatele,
    feature level Oracle 8 ('97) sice jeste porad nemame ale postupujeme spravnym
    smerem. Pockejte si jeste tak 2-3 release a budeme tam.

    Na tu javu, ale na tu rovnou zapomente a bezte radsi vyvijet aplikace v PHP, ktery ted v mate i v Solarisu. SQLJ, PL/Java ani JDBC3 nejsou a nebudou. My do Javy nedelame, jdete si napsat sve drivery.

    Drivery prece nejsou soucasti projektu. Stejne tak s replikaci, odkdy je prosim vas poradna replikace soucasti projektu? S replikaci a JDBC3 laskave tahnete do MySQL!

    Jinak bychom vam radi prestavili nas novy ultra cool syntax. My, narozdil od MySQL, mame developerskou hrdost. My se nikdy nesnizime k tomu, abychom pouze kopirovali a delali syntax kompatibilni s tou hnusnou komercni databazi O*ACLE. My jsme inovativni, mame nejen nekompatibilni syntax, ale i semantiku.
  • 5. 1. 2008 23:52

    Jirka (neregistrovaný)
    Me PostgreSQL slouzi uz nekolik let k plne spokojenosti. Nastesti to neni jako Oracle, protoze Oracle je pro me potreby neco jako kanon na vrabce. Navic drahej kanon s naprostou silenou spravou. Java v databazi? Dekuji nechci, nic proti Jave, ale v tomhle pripade radsi PL/SQL, abych u toho nezesedivel, nez se to spusti.

    Misto blbosti, ktere tu placate, byste mel jit spat. PostgreSQL je alternativa, pokud se vam nelibi, tak ji nepouzivejte. Ti lide co na tom delaji si podobne priblble komentare vazne nezaslouzi.
  • 6. 1. 2008 19:48

    Radim Kolář
    Zajimavy je, ze ty nejvetsi trollove tady sice delaji ze sebe neskutecne machry, ale jsou tak zbabeli, ze se nechteji ani podepsat.
  • 6. 1. 2008 11:02

    Pavel Stěhule
    a) jděte už do háje nebo tam kam patří zmrdi, b) než o něčem napíšete, tak si o tom alespoň něco přečtete, neb něco žvatlat dokáže každá kurva na ulici, nehledě na to, že plácáte totální nesmysly. c) cílem projektu není Oracle pod BSD licencí ale bezpečná a spolehlivá enterprise ANSI SQL OLTP databáze. Pajcováním Oracle se zabývají komerční firmy. Pokud je mi známo, tak MySQL má tolik hrdosti, že implementují vlastní features bez ohledu na ANSI, Oracle či DB2. PostgreSQL rozhodně neatakuje Oracle, a jeho segment je tam, kde je Oracle nikoliv kánónem na vrabce, ale křižníkem. Na druhou stranu už možná 8 let má features, které teprve nyní implementuje MSSQL: MVCC, externí procedury, podporu polí, podporu 1GB varcharu, podporu catch exception, atd atd. Jinak i ten Oracle je minimálně o 12 let starší než PostgreSQL, což je samozřejmě znát. SQLJ, PL/Java kupodivu existuje. Můžete si stáhnout zdrojáky, můžete je volně používat, jestli chcete. V o.s. je zvykem, že drivery se píší a udržují ve vývojových prostředích, vlastní drivery má Perl, Python, PHP a i ta Java. PostgreSQL podporuje pouze jeden driver a to libpq, nad kterým jsou postavené všechny ostatní. Jelikož se nejedná o close produkt, tak není problém vlastní driver s využitím nebo na zelené louce postavit. Obojí je velmi dobře zdokumentované:
    http://www.postgresql.org/docs/8.2/interactive/libpq.html
    http://www.postgresql.org/docs/8.2/interactive/protocol.html
    To se nedá říci o komerčních produktech, kde se kolikrát tyto informace získávají reverzním ingeneeringem, a kde napsat nový driver může být skutečně martýrium a proto je nezbytné, aby komerční fy. ke svým closed aplikacím drivery dodávaly. To, že mnohamiliónová komunita kolem Javy není sto napsat driver, který by uspokojil R.K, je pro mne poněkud nepochopitelné a nevím, co si o tom mám myslet.
  • 6. 1. 2008 12:02

    Radim Kolář
    No feature level Oracle8 sice jeste nema. Od oka chybi packages, reversed indexy, direct loady, lepsi LOB a ta Java. Ale target skupina pro PGSQL je jina nez pro ten Oracle.

    Vemte si jen kdyby MySQL a PGSQL stalo tolik co Oracle - nejlevnejsi verze $5k, myslite si ze bychom meli tolik web aplikaci co mame ted? Tezko. Pro nekomercni sferu je to idealni produkt, oni by totiz Oracle + k tomu admina tezko zaplatili. K pgsql neni dedicated admin ani potreba. Krom toho C API PGSQL je mnohem vice easy to use ve srovani Oraclem.
  • 6. 1. 2008 13:58

    Pavel Stěhule
    Některé z těch funkcí v PostgreSQL také nikdy nebudou: packages ala Oracle (PL/SQL má v Oracle jiné postavení (výhradní) než PL/pgSQL), reversed indexy (indexy jsou v pg postavené jinak, resp. výkonnostní hrdlo je jinde), ... Opačně bych se mohl zeptat, odkdy má Oracle vestavěný fulltext podporující vyhledávání podle lexémů, která verze Oracle podporuje asynchronní commit nebo synchronizované čtení, případně GiN nebo GiST indexy. Jinak řečeno vývoj PostgreSQL nekopíruje Oracle, není to cílem a není to také ani možné. Pokud ale unikátní funkce Oraclu nebo MSSQL nejsou potřeba (např. OLAP, sofistikovanější replikační a cluster řešení), tak PostgreSQL funguje velice spolehlivě, rychle a to nejen v nekomerční sféře.

    Jinak absolutně s Vámi souhlasím, že nebýt MySQL (pg se na internetu zas až tak výrazně nepodílela), tak internet v podstatě neexistuje. Licenční politika byla taková, že v podstatě www aplikace byly neprovozovatelné na komerčních databázích, hlavně kvůli nákladům na licence a to ať komerční aplikace nebo jakékoliv jiné. Pokud aplikace negenerovala několik set tisíc, tak nezaplatila ani licence.
  • 6. 1. 2008 15:11

    Radim Kolář
    packages je dalsi featura co v pgsql nechteji? Tak aspon at udelaji global variables like db2. Ach jo, zda se mi ze to s vyvojem pgsql zacalo jit skopce. Kdyz zrusili podporu INDENTITY a prohlasili to za nepotrebne tak jsem taky pochyboval o jejich zdravem rozumu, vsechny ostatni db to pochopitelne maji.

    Ja vim team chce jako ostatne vetsina OSS produktu jit svou vlastni cestou a ignorovat kompabilitu s ostatnimy DB, protoze se to poklada za kopirovani a opisovani. Low end sfere je to fuk, ale v podnikovych aplikacich vetsi crossdb kompatibilita dost bodne.

    Dost veci v PGSQL jsou nedodelky. Napriklad proc je rollforward recovery v PGSQL tak neuveritelne user unfriendly? Proc neni podpora XA? Jakou ma cenu mit 2PC bez XA? To pak tu databazi nemuzete s zadnym transakcnim managerem spojit a pgsql vlastni TM ani nema. To je dobre jen tak abychom si nekde odskrtli policko 'mame'.

    Do oracle je fulltext modul, bez toho by se snad dneska db ani neprodala. Async commit byl z Oraclu (no mozna to byla sybase) odstranen, misto toho je moznost vypnout logovani u tabulky. Synchronizovane cteni podporovano je, GiN ne. GIS aplikace v Oraclu vyuzivaji normalni indexy.

    Ja vim, problem s vetsinou OSS projektu je jejich projekt management. Dobry programator jeste neznamena byt dobrym project managerem. S OSS teamem je komunikace problematicka, tem proste nektere veci nevysvetlite.

    Naprilad vezmeme si 2 veci co lidi v pgsql chteji - HA/DR a replikaci. Kdyz se podivame jak jsou tyto veci vyresene v Oracle a DB2, tak zjistite ze v Oraclu je to resene pomerne slozite (implementace by dala dost prace), ale v DB2 je to resene velmi jednoduchym zpusobem, ktery soude podle marketshare DB2 naproste vetsine lidi dostacuje.

    Kdyz ale navrhnete obslehnout replikaci z DB2 (klidne vcetne jejiho systemoveho katalogu a jmen tabulek, proc znova vymyslet kolo a lamat si hlavu s designem Slony2 kdyz muzeme pouzit vysledky prace nekoho jineho), ktera toho umi vice nez slony1 (slony1 neni multimaster a neumi nereplikovat nektera data ci sloupce) a navic je vyrazne jednodusi na implementaci nez slony1 a ma vpodstate linearni skalovatelnost a nevyzaduje obousmerne spojeni serveru (dobre pro firewally a dynamicke IP), tak se setkate s odporem, ze MY se prece nesnizime k tomu abychom opisovali od konkurence. Elitarstvi - hlavni problem OSS projekt managementu.
  • 6. 1. 2008 16:19

    Pavel Stěhule
    Ptal jsem se od které verze Oracle tyto funkce má. Zda-li od 8, tak pak skutečně Pg není srovnatelné s 8, pokud nikoliv, tak se srovnává nesrovnatelné, a proti tomu jsem se ohrazoval. Packages kompatibilní s Oracle v pg nemá šanci, jelikož pg ještě podporuje plperl, plpython a další, které je potřeba nějak podporovat. Řešením jsou modules dle SQL/PSM. Zatím jsem napsal pouze interpret PSM. Další kroky budou možná následovat. Možná ne, poněvadž o to reálně nikdo nestojí. Což mne samotného mrzí, ale nic s tím nenadělám. Budu rád, když do 8.4 protlačím podporu skutečných procedur a funkcí. Vím, že to má daleko do úplnosti DB2 nebo Oracle. Fakt je ten, že tyto features uživatelé nepoptávají a k implementaci něčeho, co není proprané v konferenci je zřejmá nechuť. Jinak Packages velice dobře podporuje EnterpriseDB, což pro Vás určitě nebude novinkou. Podpora IDENTITY byla z 8.3 vyřazena nikoliv vůči výhradám vůči IDENTITY jako takové, ale kvůli implementaci, kdy není jasné, jestli implementace je ve shodě s ANSI. Dodatečná změna by byla horší, skoro neproveditelná. V ToDo zůstává.

    Zda-li je OSS elitářský nebo nikoliv nemohu soudit. Rozhodně je nezávislý a rozhodně si nenechá diktovat. PostgreSQL paradoxně trpí svým "úspěchem". Dokud to byla pomalá leaky trpící databáze, tak se commitovalo o sto šest. Aktuálně roste hlavně počet patchů v queue. Patrně 8.3 má nejdelší feature freeze v historii - 8 měsíců a patrně je to poslední verze, která vznikala podle 10 let používaného konceptu, což znamená, že 8.4 bude z hlediska projektu neskutečně bolestivá záležitost. Poslední poznámka .. samotný projekt jako takový nemá vývojáře .. má pouze commitery, kteří zodpovídají za kvalitu a konzistenci nově přidaného kódu. Veškerý kód napíší dobrovolníci nebo placení vývojáři, kteří řeší konkrétní problémy. Žádný jiný kód nevznikne. Samozřejmě, že v OSS nemůžete použít direktivní komunikaci, někomu něco nařizovat. S tím poměrně rychle narazíte. Jako např. narazili lidi z edb, když letos chtěli přejmenovat projekt. Na všem se relativně dost lidí musí shodnout, což má dva důsledky: relativně nižší počet implementovaných funkcí, relativně vyšší konzistenci. Mohu potvrdit, že komunikace s TOP není jednoduchá, a pro protlačení čehokoliv musí člověk vydat dost energie nebo mít dost velkou prestiž. Ale rozhodně se mi nikdy nestalo, že by mne někdo ignoroval nebo se nade mnou nějak ušklíbal. Myslím si, že Tom Lane je na konferenci permanentně, takže má perfektní přehled, co aktuálně vyžadují a jaké mají problémy. V pg prim hraje kvalita kódu, ať se to někomu líbí nebo ne (já bych třeba i z té kvality mírně slevil u develop verzí), na úkor nových funkcí - doplňuje se tak s MySQL, kde se nové funkce objevují častěji na úkor kvality.
  • 7. 1. 2008 18:39

    Radim Kolář
    8i fulltext mela, 8 nevim.

    Ja vim jak funguje OSS, prave proto ho proste podporovat financne nemuzu, protoze to bych jen vyhazoval prachy oknem a nikdy by se to nevratilo.

    Kdybych platil vyvojare pgsql tak je mne jasne jak by to dopadlo. Oni by stejne moc nechteli poslouchat sefa, ktereho bych jim pridelil a nedali by si do toho moc kecat. Kdybych nemel koupenyho project leadera tak jaka je realna sance, ze by se to co se vyvinulo commitnulo, kdyz by to byla potreba commitnout. Vedlo by to k dlouhym diskuzim. Demokracie je to nejhorsi vzhledem k ROI.

    Zbytek commiteru by se vyzival v tom jak jim hazet klacky pod nohy jak to delaji lidem od Sunu nebo z EDB. Kdyz Tom Lane nekoho od Sunu potopi s necim co se neda overit ala 'benchmark neodpovida realnemu workloadu' vase patche si strcte, nic se menit nebude tak mu jeste deticky zatleskaji jak se zbavili te hnusne komercni firmy co chce na jejich softu vydelavat. To, co by se napsalo bych potreboval mit alespon nejakou dobu closed source aby prodej licenci zaplatil vyvoj - to je dalsi problem, ktery by byl na dlouhou diskuzi. Posledni problem je ze ti co pouzivaji pgsql z principu nechteji nic platit a je jich malo.

    Proste by to nemelo ROI. Podobny je to se vsema OSS projektama proto to nikdo nefinancuje. OSS demokracie je fakt k nicemu, se stadem se nedohodnete a kdyz se chcete dohodnout, zacnou predkladat naprosto nehorazne pozadavky. Normalne takovym lidem date kopacky ale jim je prave dat nemuzete, to oni vedi, a proto si tak nehorazne vyskakuji. Projekt ktery financujete musite mit proste pod kontrolou. Tak jak to dela Sun u Solarisu, nikdo z venku mu do toho nemuze co kecat.

    Pokud lidi nepochopi ze tam clovek nedava penize z lasky k bliznimu, ale protoze chce vydelat, je to cele o nicem. Forknout PSQL nemuzu, trh je maly, hraci chudi. Jen by to zivorilo jako EDB, ani ti si nemuzou dovolit delat poradny vyvoj, Sun taky ne, o ostatnich komernich pgsql klonech ani nemluve. S Linuxem je to stejny Suse, RHEL sice nejaky vyvoj delaji, ale naprosto minimalni. Na poradny vyvoj nejsou prachy a prachy nejsou protoze OSS.
  • 7. 1. 2008 20:33

    Pavel Stěhule
    V něčem pravdu máš a v něčem ne. Je to kruh. Dokud nebyly OSS databáze, tak klasické databáze byly nekřesťansky drahé. Určitě si budeš pamatovat kolik stály licence pro web aplikace, kolik stála jedna licence. A fy. jako Oracle, IBM i ten Microsoft rostly exponenciálně. Zároveň se přiživovaly firmičky jako Borland, Solid, třeba ta naše 602, které prodávaly lehčí databáze za poloviční cenu. OSS databáze se vynořily ze tmy. Nikdo nevytvářel truc projekty. MySQL si napsali webaři sami sobě a dost dlouho to nebyl ani server, ale +/- knihovna. PostgreSQL vznikl přepsáním studentského projektu více-méně jako hobby pár nadšenců (stejně jako Linux). Nikdo ani nečekal, že by tyto projekty nějak mohly ohrozit pozice velké trojky. Kupodivu se ty databáze začaly používat a to dost výrazně. Tak výrazně, že pro malé zákazníky jsou dneska všechny databáze více-méně zdarma. Což sestřelilo 602SQL, Solid a další fy., které se živily prodejem malým zákazníkům. Dnes bohužel jediný skutečně konkurující model velké trojce je GPL nebo BSD. A to jenom díky tomu, že náklady se roznáší a na kódu může spolupracovat a taky spolupracuje řada firem. Pokud by tu nebyl PostgreSQL nebo MySQL, tak by tu byly jiné databáze, protože licence před 6-7 rokama byly takové, že by tu jiné databáze vznikly a také jiné databáze vznikaly (GNUSQL). Na těchto databázích nikdo nevydělává přímo, ale vydělává se tím, že se nemusí platit za licence. Je jasné, že kdyby se PostgreSQL prodával, tak se těch deset programátorů válí v penězích. Neprodává se. Peníze přijdou pouze od zákazníků, kteří si dokáží spočítat úsporu a kteří si dokáží spočítat, že se jim vyplatí udržovat naživu projekt. Na to kolik běží instalací PostgreSQL tak sponzoruje možná promile uživatelů. Těch 20 placených lidí se v několika miliardový populaci lehko ztratí. Navíc to dělají lidi, kteří se v kodařině skutečně vyznají a dělají to z nadšení (prostě jsi king, když napíšeš nějakou fíčuru). Kdyby OSS nějak nefungovalo, tak by neexistovalo. Je pár firem, které si dovedou spočítat, kolik by musely platit za Oracle, za DB2, Microsoft, a jak by se jim to promítlo v obratu. Tím myslím fy, které prohání víc než 1000 db serverů.

    Nemám pocit, že by někdo z core dělal schválně problémy lidem z edb nebo Sunu (jestli přijdeš na konferenci, tak tam bude Zdeněk Kotala, s kterým můžeš dát na toto téma řeč). Tom nebere polovičaté řešení - a vím o čem mluvím, nicméně kolikrát vede kodéry za ruku a dost často kód, nad kterým bručí, pak doslova vyprecizuje, že ho vlastní autor nepozná - typickým příkladem jsou updatable kurzory - celá hromada věcí v 8.3. Některý patche byly 30-40x předělávaný. Kdyby se řešilo ROI, tak jsi na nule. Na druhou stranu PostgreSQL má renomé jako žádná jiná OSS databáze - renomé se bohužel do ROI nedá zahrnout. Bez reputace by ten projekt po čase skončil. Už teď je dost patchů na 8.4 - a problém není v penězích (vím jaké jsem dostával nabídky), ale není tolik špičkových programátorů, kteří by tohle dokázali dělat. V Pg je jen několik tabu: a) hinty (o těch už byla řeč), b) embeded databáze, c) kompatibilita s Oraclem bez shody s ANSI. O všem ostatním se dá diskutovat. Bez proposals nemá cenu nic dělat, pokud máš odsouhlasený proposals tak máš skoro jistotu, že tvůj patch se dostane do Bruceho queue, kde pak může s klidem ležet půl roku nebo rok, jako moje patche. Ty nejsou ale nijak důležité. Nikdo je nijak zvlášť nechtěl, jen pár šílenců, co píšou v PL/pgSQL. Co je podstatné pro životaschopnost projektu je komunikace s obyčejnýma userama. Ze dvou bugů nahlášených minulý týden je jeden opravený a na dalším bude do konce týdne. Třeba updatable kurzory byl klasický korporátní a sponzorovaný kód.

    Ještě jednou - na OSS se nevydělává přímo, ale nepřímo. Fy., které používají OSS mají nižší výdaje. A je na nich, zda-li použijí OSS nebo nepoužijí. Nikdo je do toho nenutí. Udělat si základní kalkulaci je to nejednodušší. A totéž platí o fy. které vyvíjejí OSS. Oni mají podstatně nižší náklady, protože mohou použít kód v kterém už jsou tisíce člověko-hodin a který by menší firma v životě nedala dohromady. Zisk je úměrný vlastnímu přínosu a není srovnatelný se zisky obrů. Jenomže IBM, Oracle, Microsft zhodnocují investice, které investovali před 20-15-10 lety, proto mají tak šílený obrat a i zisk.

    Forknout si můžeš jakýkoliv OSS. Ale je jasný, že budeš mít nižší ROI než když použiješ OSS beze změn poněvadž ho používáš gratis, nebo když použiješ komerční soft, kdy licence naúčtuješ zákazníkovy. To, ale neznamená, že OSS nefunguje. Je otázka jaký bude další vývoj. Možná skončí dřív OSS, možná vydrží dýl. Pravda je ta, že Microsoftu tržně konkuruje jenom Microsoft a ten relativně těžce přesvědčuje zákazníky aby upgradovali. Lehko se povyšuje, když máš nefunkční, polofunkční verze - jako byly starší Office nebo NT. A není moc důvodů k upgrade, když máš sw, který dělá to co má dělat. Od tužky chci aby psala a nikoliv aby ještě počítala a blikala. Zrovna tak Oracle je neskutečně daleko. Ale s každou jeho novou verzí nové vlastnosti využije méně a méně zákazníků. Už teď, kolik reálně firem využívá funkce SQL Serveru nebo Oracle (např. Olap). Padlo to v jiné diskuzi, OSS není přátelský vůči vývojářům (hlavně GPL), ale vychází vstříc zákazníkům, kteří dostávají sw, který skutečně potřebují a nikoliv sw, který jim vnutí dodavatelé. Už jsem se zase rozepsal. Sorry.
  • 6. 1. 2008 20:31

    j.peterka (neregistrovaný)
    jsem prekvapen, ze na webu, kde by ocekaval clovek min. 50% vysokoskolaku je takovy problem videt veci diferencovane. Hazi se tu ficurkama a pritom vystaci 95% vsech aplikaci se spravou dat v textovych souborech. Prevazna vetsina vsech svetovych dat se spravuje i nadala VSAMem.

    Je to zdrcujici, jedna se o zpracovani dat. Jako kdyby jsme se bavili o doprave z mista A do B a pan Kolar by nam sdelil, ze ty nakladni auta v tom diamantovem lomu na Sibiri uvezou naraz 50 tun a to ten LIAZ nedokaze.
  • 6. 1. 2008 21:17

    Rejpal (neregistrovaný)
    Hazi se tu ficurkama a pritom vystaci 95% vsech aplikaci se spravou dat v textovych souborech.
    Sice používám S-výrazy (vzhledem k vlastnostem mého jazyka je to mnohem komfortnější), ale vidím to úplně stejně. :-)
  • 7. 1. 2008 0:06

    Radim Kolář
    1. vsam ma k textovym souborum dost daleko.
    2. Unix/Win neumi strukturovany pristup k souboru, mainframe OS ano
    3. DB2 bezi nad VSAMem.
    4. Mainframe OS umi zajistovat napriklad integritu dat, auditing, archiving a recovery

    Takze VSAM se nerovna to, cemu se na unix/win rika textovy soubor. Textovy soubor a OS pod nim zadnou takovou funkcionalitu nenabizi.

    Banka by tezko skladovala data klientu v textovych souborech se sekvencnim vyhledavani, bez transakci a recovery.

    Jinak mainframe programovani to je fakt hruza. Jazyk z praveku, ladici nastroje take a replay journalu se opravdu nepredre - ten software pocita uz s tim ze tyhle masiny prakticky necrashnou, protoze je i u relativne malych souboru schopen delat replay hodiny. Prace s paskou no to je taky unikum, zajimavy ze maji porad jeste podporu pro zalohovani na floppy disky.

    Otazka neni zda to staci ci ne, programovat v COBOLU, JCL, PL/I a podobnych vykopavkach se proste nevyplati z duvodu nizke produktivity, jsou to jazyky z roku ~ 1960.
  • 7. 1. 2008 3:19

    Miloš (neregistrovaný)
    Každý jazyk stárně. Nicméně PL/1 byla naopak jazykem velice produktivním. Chybějící databáze ovšem nahradit nemohla. Pokud je pomineme, tvrdím, že tato vykopávka byla produktivnější, než třeba současná Java. Horší bylo, že šlo o jazyk nedeterministický a jeho devítiprůchodový kompilátor překládal pět stránek programu skoro hodinu. Dnes naprosto nepředstavitelné.
    Stejně, jako pracovat s hromadnými daty bez databáze. Ovšem páskové stojany těchto mašin byly pro archivaci dat ideální (snad proto se používají dodnes) a nikdy jsem nepochopil, proč se neobjevily u serverů.
  • 7. 1. 2008 9:38

    Rejpal (neregistrovaný)
    Horší bylo, že šlo o jazyk nedeterministický a jeho devítiprůchodový kompilátor překládal pět stránek programu skoro hodinu. Dnes naprosto nepředstavitelné.
    Nikdy jsi neviděl v akci Stalina? ;-)
  • 7. 1. 2008 11:42

    Radim Kolář
    Aha uz mne doslo, co mate na mysli. Ty databázové soubory se umí v mainframe OS tvářit i jako textové soubory a dokonce i jako tabulkové soubory. Ostatně to by se pak mohlo říci i oraclu ze je to textovy soubor, kdyz udelate SELECT tak z toho take leze text.

    Krom toho ta nesql databaze umi referencni integritu, materializovane views, partitioning, 4 druhy indexů, transakce, auditing, recovery, online backup, checkpointing.

    Dulezity bod ale je, ze kdyz se vám například nechce joinovat nebo sortovat na aplikační úrovni, tak stačí program linkout s SQLLIB (tak se jmenuje sql databáze db2) a máte okamžitě k dispozici kompletní SQL support pro přistup k těm stejným datům.

    Takže ukládáním dat do těchto souborů žádnou funkcionalitu neztrácíte. SQL máte k dispozici na požádání. Pokud například jen vkládáte záznamy řekněme do 3 tabulek, tak to se dá udělat i ručně, bez použití SQL.

    Kdyby k těm datům SQL přístup nebyl, tak pochybuji že by mainframe sales ještě dnes rostly.

Byl pro vás článek přínosný?

Autor zprávičky