Názory k článku Migrace aplikace z Oracle do PostgreSQL - Root.cz\nRoot.cz » Databáze » Migrace aplikace z Oracle do PostgreSQL » Všechny názory\nNázory k článku Migrace aplikace z Oracle do PostgreSQL\n6. 9. 2017 6:12\npo dlouhé době okurkové sezony tu a tam prokládané tragediema typu https://www.root.cz/clanky/analogovy-zaznam-analogoveho-signalu-na-digitalnim-pocitaci/ BOMBA článek - víc k tomu nelze dodat.\nMoc pěkný článek. Oracle používáme a zatím si neumím představit, že bychom u hlavního projektu (ISKN) přešli na něco jiného. Využíváme hodně vlastností Oracle jako je Partitioning, Spatial, Virtual Private Database, RAC, XML DB, Advanced Security apod., což se na něco jiného migruje blbě (ale zase to přináší dobré vlastnosti, funkce a zjednodušení). U nás je ještě ten problém, že aplikace jede v Oracle Forms a Reports, což v podstatě jinou DB vylučuje.\nVyužívali jste nějaké takové speciality? Pokud ano, jak jste to při převodu řešili? Věřím tomu, že pokud se používají jen standardní věci, základní SQL, pohledy, package, tak to určitě rozumně migrovat jde (i když práci to dá).\nJe to vždy dilema - když si pořídím produkt, tak ho využít do mrtě, ale za cenu, že se od něj budu hůře odpoutávat? Nebo na něm moc závislý nebýt, ale zase budu muset řešit spoustu věcí, které ten produkt sám umí (a určitě lépe).\nMe by zajimalo jestli existuje funkcni nahrada Oracle AQ u Pg ... zkousel jsem si hrat s nejakou implementaci ale byla to hruza ...\nex (neregistrovaný) ---.cust.tele2.se\nISKN musi bezet na Oracle, protoze penize :-( Ale abych byl uprimny, centralni DB bezet na Oracle muze, ale nechapu, proc lokalni DB pro obnuvu bezely (aktualni stav nevim) naOracle take, to tedy nechapu. A casto diky neschopnosti pridelenych pracovniku byly v takovem strasnem stavu, ze by to zvladlo i kdecos jineho. Ale Oracle neni nejvetsi problem ISKN, tam je treba resit mnoho jinych koncepcnich zalezitosti.\n6. 9. 2017 6:45\n6. 9. 2017 8:42\nKonečně pořádnej zajímavej článek.\n6. 9. 2017 9:27\nclanok je dobry, business logic v databaze je ZLO\ntomie (neregistrovaný) 46.13.12.---\n6. 9. 2017 10:24\nTiez si myslim, ze databaza by si mala byt schopna konzistenciu a spravnost udajov udrzat sama... najma pokial sa do nej pristupuje z rozdielnych aplikacii\nDost blbe se to skaluje ... proste zabijete CPU/CPUs DB vykonem appl logiky ale co kdyz dojdete do stavu ze to proste uz DB nedava ? Pridavani aplikacnich serveru jde v podstate do "nekonecna".\nNavic kdyz potom narazite na "specialistu" co tu appl. logiku v DB okoreni triggerama ;-) je na pruser zadelano.\n7. 9. 2017 14:34\nBottleneck na db jsou SQL příkazy - a těch pustíte stejně, ať používáte jeden aplikáč nebo deset nebo máte logiku v uložených procedurách. Zátěž db serveru je +/- stejná. Pokud máte logiku v uložených procedurách, tak vám odpadne část síťových latencí, ale to gro je stejné.\nLogika v db neznamená, že v db děláte všechno - v db dělám jen manipulaci s daty. O prezentaci, komunikaci se mi stále stará aplikační server.\nVětšinou s Vámi souhlasím, ale tohle je naprostá blbost. Chcete mi snad tvrdit že když budu mít v jedné tabulce zadání nějaké výpočetně složité úlohy (řekněme třeba těžení bitcoinů, ať je to dostatečně moderní) a do druhé tabulky budu psát výsledky tak bude zatížení databáze stejné ať už ten výpočet budu provádět přímo v databázi nebo na spoustě aplikačních serverů?\nViděl jste už někdy, že by se v uložených procedurách těžily bitcoiny? PL/SQL, PL/pgSQL - to jsou jazyky pro lepení SQL - a typicky nejnáročnější výpočetní úloha je počítání ekonomických koeficientů. Bavíme se o databázích, o nějakém účetnictví, evidenci. Nezažil jsem nikdy, že by někdo použil jazyk DBase nebo FoxPra pro nějaké výpočetně náročné úlohy - ray tracing, lámání md5 hesel, atd. Totéž nikdo nebude, se zdravým rozumem, dělat v uložených procedurách. CPU zatížím v momentě, kdy si nechám spočítat skrz SQL agregaci a náhodou mám data v cache v RAM. Jinak většinu času se čeká na IO.\nCo znám, tak výpočetně nejnáročnější operace, které se dělají nad databází a v databázi jsou PostGISové transformace - což je z hlediska PL/SQL naprosto hraniční úloha.\nPokud se mi v kódu nevyskytují SQL příkazy, nedělám žádné manipulace s daty, tak nepoužívám prostředí uložených procedur.\nNení pravdou. Je záhodno navrhnout aplikační server s cacheováním, a tím nemyslím na straně RDB, ale u objektových systémů především z druhé strany ORM, tj. cacheování už seskládaných objektů! Tím nejenže klesne počet čtení a zápisů do RDB, protože je ap. server výhradním uživatelem RDB a objekty klientům poskytuje už hotové, ale také odpadne opakované „sestavování“ „objektů“ v uložených procedurách RDB. Koneckonců proč by se RDB měla snažit simulovat objekty, když to neumí?\nTo minus mas ode me, ukliknul jsem se, promin.\nNo jasne, neni nad to psat stejnou business logiku 3x v 3 ruznych jazycich ze? Se vzpamatuj, BL v databazi je poklad, jediny zdroj pravdy.\n6. 9. 2017 14:08\nneni nad to debugovat nejaku komplexnejsiu business logic v PLSQL...zazil som a nikdy viac.\nku tomu version control, deployment...proste ZLO\n6. 9. 2017 15:05\nDebuguji PL/SQL poměrně často (nástroj PL/SQL Developer). Co přesně na tom je zlo? Mně ten debugger přijde prakticky stejný jako třebas v C#. Má to step into, step over, breakpointy (včetně podmínek typu zastav se teprve až tenhle breakpoint bude dosažen po sté), zobrazuje hodnoty proměnných, call stack atd. V čem konkrétně ten debugger zaostává za jinými jazyky?\nVersion control záleží na editoru. Pokud máte editor provázaný s version control systémem, tak je to stejné jako jakékoliv jiné IDE. Pokud měníte objekty pomocí SQL*Plus nebo jinak napřímo, pak ano, je to špatné.\nDeployment je o tom, jak chcete psát zdrojové kódy. Velké aplikace se běžně píší tak, že všechny .sql soubory prostě v nějakém pořadí spustíte znovu. Prostě místo CREATE TABLE nejprve otestujete, zda už tabulka existuje, a ten CREATE spustíte jen pokud ne. Sloupečky doplňujete tak, že se kouknete do all_tab_columns a podle toho se rozhodnete, zda ten ALTER TABLE je potřeba udělat. Bordel jsem s tím zažil jen ve firmě, která zvlášť držela create scripty a zvlášť upgrade scripty. Tam to byla noční můra v udržování patch version - to aby se něco nezapomnělo sputit, ale zároveň se to nespustilo více než právě jednou. Přitom to není nutné, scripty mohou být snadno znovu spustitelné. A u věcí jako jsou view a package je opakovatelná spustitelnost by default.\n8. 9. 2017 11:40\nSupr, to máte pro Oracle. Jak zvládají debugování další RDB? A jak řeší debugger ORM? Máte totiž tabulky, ale ve skutečnosti potřebujete objekty, lobo se totiž ptal na „business systems“, ne na meteorologickou stanici.\nbusiness systems nemusí znamenat objekty - to je utkvělá myšlenka - s uloženými procedurami se implementují procesy - píši systém, který podporuje procesy, které zákazník potřebuje. Objekty řeším maximálně na úrovni UI. Klíčová slova jsou "data" a "procesy".\nDebuggry už jsou k dispozici pro všechny databáze, které umí uložené procedury. Samozřejmě asi vazba ORM/databáze bude asi vždy skřípat.\nNetvrdím, že to ORM není v určité oblasti standardem - to je asi to nejsmutnější - že v podstatě jeden z nejhorších nápadů v historii IT se takhle prosadil.\n11. 9. 2017 12:06\nPane Stěhule, melete to samé pořád dokola! Obchodní (business) systémy pracují s entitami, které mají z povahy věci vlastní vnitřní seznamy a vzájemně jsou uspořádány do grafu. Dokumentová DB zvládá ty seznamy, grafová či objektová oboje. RDB ani jednu z těchto dvou vlastností neumí!!! Takže to musíte v oné RDB nějak nasimulovat, a to rozkladem do tabulek a poté jejich opětovným spojováním. Jestli tvrdíte, že v uložených procedurách se obejdete bez ORM, tak se mýlíte, protože právě to dohledávání jednotlivých částí obchodních entit v tabulkách je právě ono ORM, i když v takové primitivní podobě.\nTakže shrnuto: Obchodní systémy jsou grafové, k čemuž opravdu nemusíte užít objekty, ale je to velice výhodné. Naopak jejich uložení do RDB je snad nejhorším možným způsobem uložení a zpracování (myslete si o tom, co chcete). Samotné uložené procedury pak znamenají se svým procedurálním členěním, omezenými datovými strukturami a nízkou abstrakcí uvíznutí v informačním středověku.\nMimoto zaměňujete příčinu a následek - ORM není jedním z nejhorších nápadů v dějinách IT, to je jen řešení původního průseru, a to použití RDB na grafové systémy.\n11. 9. 2017 14:55\nPostgres, a dneska skoro všechny moderní RDB mohou fungovat jako dokumentové databáze.\nNevím, kde jste přišel na to, že všechno musí být v grafech - každá struktura má svoje výhody a nevýhody - grafové databáze velice dobře dokáží zachytit vztahy, ale umožňují vyhledávat cesty - ale velice špatně se na nich počítá účetnictví - a pokud se nevejdete do paměti, tak je to zoufale pomalé.\nZase na RDB se účetní úlohy počítají skvěle - ale na grafy to fakt není. Nicméně, že by grafy byly nutnou podmínkou v bussiness, toho jsem si opravdu nevšiml - historicky to byly první databáze - posléze se výrazněji prosadily relační databáze - primárně kvůli lepšímu poměru cena/výkon.\nOpravdu záleží, co děláte a co považujete za Bussiness systém. Relační databáze se neprosadily jen kvůli marketingové síle IBM (té možná navzdory). Je to datový model, který přináší určité zjednodušení, na druhou stranu typické socioekonomické úlohy zvládá velmi dobře.\nInformačním středověkem jste mě pobavil :) - podívejte se na historie databází - a čím se začalo.\n12. 9. 2017 11:59\nO použití Postgressu jako dokumentové DB tu nikde řeč nebyla. A máte na mysli předstírání organizace dat do dokumentů, nebo uložení jako dokumenty?\nNemluvil jsem o uložení v grafech, ale o tom, že obchodní systémy JSOU grafy!\nRel. model nepřináší žádné zjednodušení, je to jiná organizace dat! A na to zvládání úloh mám mnoha lety podložený vlastní názor.\nUfff... Nejde o to, čím se začínalo, ale co je teď!\nAsi to tu nemusíme protřepávat, zjevně si nerozumíme, vy se budete věnovat svým RDB, já zase něčemu jinému. Svoje názory jsme řekli.\n11. 9. 2017 19:56\nTakže to musíte v oné RDB nějak nasimulovat\nTo je nepochopeni RDB. Rozklad do tabulek a jejich skladani nic nesimuluje. To je jen jiny zpusob reprezentace informaci (dat).\nJestli tvrdíte, že v uložených procedurách se obejdete bez ORM, tak se mýlíte, protože právě to dohledávání jednotlivých částí obchodních entit v tabulkách je právě ono ORM, i když v takové primitivní podobě.\nNeni. ORM (Object-Relational Mapping) je jen zpusob, jak namapovat objekty na relacni data a opacne. Coz je opravdu jeden z nejhorsich napadu. Hlavni problem je v tom, ze v objektovem sveta je objekt (entita) dan svou identitou, mistem prirazenym v pameti. V RDB svete je objekt (entita) dan svymi vlastnostmi (prinejmensim hodnotami prim. klice). Toto na sebe naroubovat a nezblbnout, chce dost prace.\nPri pouzite ORM typicky vznikaji dva problemy. Nepochopeni objektoveho programovani nebo nepochopeni relacnich db. A pak z toho vznika prasepes s hromadou problemu.\nObchodní systémy jsou grafové\nNikoliv nezbytne. Zalezi jenom na tom, jak se na ta data chcete divat. Jestli jako na nejake objekty, ktere jsou spolu provazany (to chces ty), ci na hromadu informaci, ktere se daji ruzne transformovat pomoci par jednoduchych operaci. (to chce p. Stehule)\n8. 9. 2017 18:39\nKarel (neregistrovaný) ---.116.23.98.static.ip.windstream.net\nOn ale zmínil právě PLSQL. To je programovací jazyk implementovaný v Oracle.\nA také psal o "business logic", což je procesní model. S objekty to nemá nic společného. To jsou takové ty diagramy "přijde požadavek na vložení objednávky, ověřím, že zákazník existuje, ověřím, že zákazník nemá credit hold. Pokud má credit hold, tak ověřím, zda požadavek má nastavený příznak ignorování credit holdu..." To snad dnes do objektů necpe nikdo? V čem by tam komu objekty pomohly?\nPokud použijete ORM, tak necpěte žádnou logiku do databáze. Prostě si při startu aplikačního serveru stáhněte všechna data a udělejte si z nich vlastní model v paměti. ORM vrstva pak bude sloužit jen k tomu, že změny zapíšete do databáze tak, aby si je aplikační server mohl znovu stáhnout po restartu. Pokud nemáte dost paměti, tak si můžete ORM vrstvu upravit tak, aby tahala data jen k těm objektům co právě potřebuje. Plus nějaký garbage collector co je zase uvolní až nebudou potřeba.\nKombinovat ORM a PLSQL je prostě kravina. Pokud to děláte, tak se střílíte sami do nohy. Pak se nedivte, že to kulhá.\nOtázkou je, zda má smysl nechat přistupovat přímo k DB tři různé jazyky (predikuji, že kvůli třem různým aplikacím) a neudělat raději v tom případě API, které tu logiku interpretuje :-)\nAno, pokud DB je zároveň API díky svými RULES a má zároveň v sobě nástroje version control a deploy. Jinak je IMHO menší zlo vést BL ve třech jazycích.\ndannak (neregistrovaný) ---.commerzbank.com\nA neni precijen jednodussi a vyhodnejsi vystavit ven nejake API a idealne aplikacni vyvojare do DB vubec nepoustet ? Vetsinou to totiz nekonci nicim dobrym; IFy a LOOPy kam se clovek podiva, indexy pomalu nad kazdym sloupcem, zadnej partitioning, takze pak v DB kvetou tabulky s 1G radkama a "zvetsime pocet threadu, to musi bejt rychlejsi".\nZa me naopak aplikacniky do DB nepustet a jen jim date k dispozici API/sluzby, nacez\n1) si muzete doladit fyzicky model jak potrebujete, resp. jak je to optimalni z pohledu dane DB\n2) kdyz to situace vyzaduje, upravit/ladit SQL aniz by se muselo testovat X aplikaci\n3) pokud to jde, muzete aplikaci udelat asynchronni - z aplikace rvat pozadavky do fronty a tu pak zpracovavat davkove\n4) oblibeny "univerzalni dotaz" (neni zrejme, co bude na vstupu a tedy podle ceho se bude filtrovat, takove to "column = :x or :x is null") nahradit treba nejakou inteligentni procedurou, ktera posklada dotaz podle potreby atp.\nProč, když to databáze umějí a správně napsaná aplikace nad SP bude vždy rychlejší - a (můj osobní názor) čitelnější - SP vás donutí do dekompozice - databázové věci řeším na databázi, prezentační, komunikační v aplikaci. Navíc SP vám umožní zabezpečení, které v aplikaci nikdy nemůžete dosáhnout.\nK dispozici jsou debuggery, profilery, verzování, deployment - není rozdíl od jakéhokoliv programování. U Oracle PL/SQL se používá jeden z nejlepších a velice dobře navržených programovacích jazyků - je to založené na ADĚ - i když to Oracle trochu zkryplil.\nProblém jsou programátoři - s Javou většinou začínali junioři - lidi s čistou hlavou. SP historicky psali vývojáři odrostlí na Cobolu, DBase, FoxPro - a nikdo jim dostatečně důrazně nevysvětlil, jak se má psát - prasí se i v Javě a to většina programátorů dneska nemá návyky z Basicu nebo C. Metodologie vývoje v SP jsou k dispozici od konce devadesátých let - ale v korporátech kvalita kódu je to poslední, co se řeší - přebírá se jakýkoliv kód, který nepadá - a pak většina programátorů nemá motivaci, znalosti, čas, zkušenosti psát čistě.\nV týmu co jsem, chlapi přecházeli z PCFandu na Oracle - bez jakýho-koliv proškolení a to musí být vidět. Tak je to skoro všude, kde jsem byl, kde jsem se bavil s programátory.\nKlasický problém rozhodování mezi variabilitou řešení a nějakým výkonovým bonusem, o kterém se dlouze můžeme bavit, jestli stojí za to. Jak to funguje v praxi?\nTřeba takový SAP zákazníkům oznámil, že od verze S/4 prostě budou mít natvrdo HANA a kdo dosud spokojeně provozoval třeba Oracle, může si jít trhnout nohou. Jakmile těch databází máte víc, začne mít význam otázka, zda je vůbec chytré mít pro každou aplikaci databázi od jiného dodavatele, protože ten bordel je pak radost spravovat.\nTakže když nemáte business logic v databázi, můžete se jednou prostě rozhodnout, že místo v Oracle budete provozovat MS SQL nebo třeba ten Postgress, klient v ideálním případě jen změní ODBC driver a jede se dál. Divil byste se kolik drahých a profesionálních řešení takto funguje, protože zákazník si chce databázi volit sám.\nJe hromada aplikací u kterých je to jedno - ale u databázově, datově náročných aplikací to nemůže fungovat - každá databáze má trochu jiné charakteristiky, co se týče chování při UPDATE, DELETE, SELECTech, mají jinou implementaci zámků -- určitě jsou aplikace, které mohou běžet jak na Oracle, tak na MySQL - ale pak, proč bych si instaloval Oracle? Ty jednoduché dotazy, které vygeneruje ORM budou stejně dobře běžet na Oracle, tak na MySQL. A InnoDB engine při jednoduchých operacích bez problémů může zastoupit Oracle. Spolehlivost dostupnost je stejná. ORM dokáže skrýt rozdíly v syntaxi, ale logika zůstává stejná.\nUrčitě nepochybuji, že takových řešení je hodně - a cena nesouvisí s kvalitou. Nicméně pak máte aplikace, které počítají mzdy pro pár desítek tisíc lidí několik hodin a po celou tu dobu intenzivně vytěžují hw. Přičemž po optimalizaci by běžely několik málo minut - někde to nemá smysl řešit - někde můžete mít problémy s efektivitou práce se systémem - odpovídající železo může být extrémně drahé atd.\nTak si tu otázku otočte. kolik takových brutálně výpočteních aplikací je? Naprosté minimum. Většina databází jen zapisuje transakce a odpovídá na různě komplikované SELECTy. Rozdílu ve výkonu si nikdo nevšimne. Zato nutnosti koupit licenci na ORACLE, když má firma volné licence k MSSQL, to už za povšimnustí stojí. Stejně jako povinnost najednou provozovat jinou databázi než zbytek firmy. V mém předchozím zaměstnání jsme měli desítky aplikací, hromadu Oracle databází, lidi co tu tento typ DB dobře znají, a všechno provozováno na clusteru s RedHatem. No a když pak najednou nějaký inteligent vyrobil nebo nakoupil nějaký super SW, který měl logiku zadrátovanou v MSSQL a nešel na ničem jiném provozovat (ono stačí když má aplikace driver jen pro jednu DB), najednou jsme museli řešit, kdo to bude supportovat, kde se to bude provozovat (na RedHat/Oracle Dlusetru asi těžko), k tomu nějaké to školení (protože to bylo první MSSQL ve firmě) a takhle bychom mohli pokračovat. Situace totálně k hovnu. Proto business logic do DB, není li to nezbytně nutné, fakt ne.\nBTW neumím posoudit zda má MySQL stejné možnosti pro mission critical naazení jako ORACLE, nicméně o tom fakt pochybuji.\nMission critical je buzword - pokud se jedná o opravdu kritické aplikace, tak tam asi nemá co dělat klasická relační db - a zbytek - dostupnost db je dneska +/- stejná - většinu výpadků způsobí síť, lidská chyba nebo problémy v aplikačním sw. Včera jsem se bavil s lidmi z jedné opravdu velké fabriky - a za problémy mohl nový planner v Oracle 12.\nJsou aplikace, kde procky nemají velký význam. Jsou organizace, prostředí, mix použitých licencí, kde mohou způsobit problémy - zrovna tak jsou oraganizace, které mají logiku v DB a jsou spokojení.\nMission critical je cokoli, kde hodinový výpadek způsobí "velké ztráty". Skutečně nechápu, proč by u systému, kde výpadek 1hod je zcela nepřijatelný a maintenance se plánuje jednou ročně na svátky, neměla být relační databáze. V drtivé většině těchto případů je totiž použita právě relační databáze.\n6. 9. 2017 20:34\nPak nasazení PostgreSQL nebo MySQL je stejně dobré jako Oracle - znám zákazníky, kde by jejich výpadek způsobil "velké ztráty" - samozřejmě, že Oracle je v této oblasti víc zaháčkovaný - v korporátním byznysu je od osmdesátých let - MySQL od konce devadesátých a Postgres po roce 2005 - zejména pak po roce 2010, v reakci na krizi a úspory v IT, kdy Pg začaly více používat korporace. V Japonsku, a např. i ve fabrikách, které zde vlastní japonské korporace se Pg relativně dlouho používá pro řízení linek, řízení provozu. Skype jede nad PostgreSQL. Facebook, Google nad MySQL.\n6. 9. 2017 21:34\nToto nijak nerozporuji. Hlavní rozdíl mezi Oracle vs. MySQL + Postgres bude celý ten cirkus okolo placeného supportu, certifikací, garancí apod., které ovšem tvoří důležitou součást rozhodování v korporátech. Sehnat někoho, kdo vám smluvně něco garantuje bude asi výrazně snazší s Oraclem.\nTo že velké Internetové firmy používají OSS databáze svědčí o tom, že to jsou možná lepší řešení než proprietární Oracle. Když na to máte prostředky a lidi, můžete si to tunit dle libosti, a nejste závislý na tom co vám chlapci z Oraclu milostivě sdělí a dovolí. Ta firma má horší pověst než Microsoft :-D\n7. 9. 2017 7:14\nnázory hezké, poté příjde požadavek na auditing, goverance, nějaké to ISO a jiné korporátní úžasnosti a vaše MySQL,Postgres s REST API či mnoha napojenými aplikace neuspěje.\nPostrgres pořád trpí v HA, integrace s LDAP není bezproblémová, dělat snapshoty není ono, tady třeba Oracle, Teradata, db2 (či jak to pojmenovali letos) vítězí a není to srovnatelné s open source.\nTím nebojuji za druhou stranu, mám tyhle open source databáze rád, nepotřebuji certifikace, velké manuály a vše si nastuduji ze zdrojových kódů, problémy se dají řešit přímo s vývojáři a ne indickou podporou. Jen někdy objektivní rozhodování právě odůvodněně končí u těhle velkých a drahých zmetků.\nDůvod proč internetové firmy používají OSS je nepřítomnost státní regulace, GDPR ukáže jak si na tom OSS stojí. U těch opravdu velkých společností došlo k vytvoření vlastních technologií, které už nejsou otevřené a drží si je pod pokličkou, do komunity uvolňují jen drobky, mluvím o Googlu, Facebooku a dalších.\n7. 9. 2017 8:52\nPokud legislativa vyžaduje Oracle, tak s tím asi nikdo nic nenadělá - taky hromada interních předpisů v korporátním prostředí jsou psaný pro Oracle. Na druhou stranu některé certifikace prorazilo EDB a ještě Sun. Data v pg je možné zašifrovat, existuje extenze pg_audit, kterou lze použít, pokud je to vyžadováno. HA lze realizovat několika možnými technikami - na Slovenské poště jsem viděl řešení na bázi NetApp - obdobu Oracle. Globální eshopy, které běží nad Postgresem, běžně dávají k dispozici svoje HA řešení (zelando/patroni).\nCo myslíte pod pojmem snapshot?\n8. 9. 2017 6:18\nOsobne nemam vylozene spatne zkusenosti s oracle supportem, nehlede na to, ze ho zas tak casto nepotrebuju. Vse je o lidech. Pokud ma firma Oracle DB (z jakehokoli duvodu), tak k nemu musi mit i opravdu zkuseneho DBA, ktery dokaze nejen rozsirovat datafile. To stejne plati i o oracle pl/sql vyvojarich. Ono kdyby si kazdy precetl developers guide, tak tam se docte hodne uzitecnych informaci co a jak a kde pouzit, aby ta aplikace slapala dobre. Za me je Oracle naprosto vynikajici databaze, ktera nabizi neskutecne mnoho moznosti co se administrace i vyvoje tyce. (samozrejme ze administruji prevazne Oracle, takze proto ta chvala ;-)\nNe, tyhle velké firmy nepoužívají Oracle zejména kvůli ceně licencí. Pokud jste velká fabrika, tak si na ten Oracle za milion dolarů vyděláte. Pokud jste Facebook, tak už je pro vás výhodnější si najmout armádu lidí, než platit Oracle za licence stovky milionů dolarů.\nZkrátka proti sobě bojují dvě křivky: mzdové náklady na vlastní lidi a fakt, že Oracle má licence za procesor. Od jistého počtu procesorů se vám tudíž vyplatí mít vlastní lidi, co budou udržovat něco levnějšího. Do jistého počtu je naopak levnější držet si jediného pičičmundu DBA a zaplatit si jednou za šest let licenci Oracle.\n7. 9. 2017 11:53\nObecne by se s tim nazorem dalo i souhlasit. Jsme se tedy trosku v diskuzi odchylili od tematu clanku, ale ja mam pocit, jako by hodne lidi v DB videlo pouze ty ulozene tabulky a nic vic. Oracle je drahy, ale taky za tu cenu nabizi opravdu hodne a je jen na firme, aby dokazala vsechny feature vyuzit, coz se (podle me) v 95% nedeje, ale to neni problem Oracle. Uz jenom to, ze kazda feature ma tisicistrankovou doc o necem svedci a to si dovolim tvrdit, ze Oracle ma zdaleka, zdaleka nejlepsi dokumentaci (pisu o DB dokumentaci).\n7. 9. 2017 14:25\nJestli má vlastnost tisícistránkový popis, tak je to především důkazem, že soudruzi z Oracle to trochu překombinovali (připomínám KISS).\n7. 9. 2017 14:37\nBylo to mysleno tak, ze je veliky rozdil v dokumentacich pro dany produkt. Co jsem se studoval dokumentaci k mssql,db2, mysql, tak vsude se tak nejak skace od niceho k nicemu. V oracle dokumentaci je vse krasne a jednoduse popsano a vysvetleno, ma to hlavu a patu a snadno se v tom orientuje.\nJeste je tu jeden faktor. Oracle je totalne zabugovane databaze. Opravdu jsou v stovky chyb ktere nikdo neresi. Pokud ale postupujete podle booku (guidelines) tak na tyto chyby prakticky nikdy nenarazite. A na kazdy problem, ma Oracle reseni. Chete HA, mate sadu reseni na HA. Chcete replikaci, sifrovani, messaging, ... na vsechno existuje guideline, technologie, priklady. Jakmile ale zkusite neco "originalniho", tak tezce pohorite.\nPostgre, na to jde uplne obracene: "Mas roota? Tak si pomuz sam".\nSamozrejme se ten prvni pristup vyce vyhovuje velkym korporacim, ktere mohou ze dne na den prenest podporu nekam do Asie, a porad maji jistotu ze je v nejhorsim pripade z problemu dostane Oracle support. Zatimco druhy pristup vyhovuje start-upum jako je Google anebo Facebook, ktere jsou zvykle spolehat na vlastni zamestnance.\nTohle jsem zažil v jedné známé, čistě české, větší firmě (a nepochybuju o tom, že to tam tak chodí doteď): Systém se nasazoval u zákazníků, přičemž každý měl jiný typ databáze - všechny draze licencované, všechny stály za hovno (2 z nich tu už padly). Takže o databázi bylo rozhodnuto zákazníkem, systém tedy musel umět pracovat se všemi. Vzhledem k tomu, že aplikační logika byla z velké části nadrátovaná do DB, všechno se dělalo 3krát, protože, jak víme, databáze nejsou kompatibilní nejen v PL/SQL, ale často ani jen v SQL. Každá z nich se ladila jinak (a to těžce). Umrdalo se na tom UKRUTNÉHO času, a když říkám UKRUTNÉHO, tak tím myslím UKRUTNÉHO. Triviální operace řešitelné ve vyšším jazyku se složitě patlaly v procedurální DB. V podstatě se většinu času jen řešilo, jak co v PL/SQL spočítat a jak to potom opravit, když to bylo blbě. O vyjadřovacích schopnostech PL/SQL se tu předpokládám nemusím rozšiřovat. Vzhledem k tomu, že systém byl podstatou objektový, je jasné, jak „jednoduché“ bylo dělat změny v objektech rozstrkaných do tabulí. Nějakou konzistenci dat při čtení objektů z více tabulek více připojenými klienty tu ani nezmiňuju. Do toho každý klient přistupoval do DB extra a řešil si konzistenci (tím nemyslím pár posraných cizích klíčů) sám.\nSprávným řešením je nechat DB jako ukládadlo, nad to aplikační server, který si jako jediný a sám pořeší persistenci (třeba nad několika databázemi i různých typů, či službami (HTTP), prostě zdroji, nak kterými řeší konzistenci), a přes API aplikačního serveru nechat komunikovat dohodnutým protokolem klientské aplikace (v jakékoliv technologii; u objektových systémů pochopitelně objektově). TEPRVE AŽ při potřebě optimalizace vyhledávacích či výpočetních operací jich pár zadrátovat do DB. Drtivá většina operací typu „otevři formulář s fakturou“ nebo „překontroluj fakturu“ žádnou optimalizaci nepotřebuje, naopak řešit takovouto vysokoúrovňovou úlohu v DB je PEKLO!!!\nKdyž slyším, jak se někdo snaží 300 000 řádků sraček překydat do jiného chlívku, je mi na blití. Ale kdo chce kam, pomozme mu tam.\nPL/SQL je ADA - a ADA je velice kvalitní jazyk - tam asi problém není - jedině v programátorech.\nMyslím si, že největší problém je, že se programátoři snaží v relačních db programovat objektově - to nejde (jsou to dva rozdílné světy) - a pak jsou z toho zbytečně frustrovaní - a pokus o objektové programování v prostředí, které není z principu objektové, nemůže nikdy dopadnout dobře.\nnick1 (neregistrovaný) ---.ipv6.broadband.iol.cz\n"systém byl podstatou objektový" ... no jo, a co jineho jste pak cekal od relacni databaze? od kdy je PL/SQL objektovy jazyk, potazmo SQL? zamyslel jste se nad tim vubec?\n8. 9. 2017 10:50\nPane nick1, my se nyní nebavíme o skutečnosti, že objektový systém v relační DB je složitý, nyní řešíme, kde má ležet aplikační logika, zda v DB, nebo vyšší vrstvě (bez ohledu na typ DB). To, že v dané firmě o jiných typech DB nemají ponětí a že je práce s RDB do aplikací tak zadrátovaná, že je stejně nenahraditelná, je věcí jinou. Mimoto připomínám, že RDB pro objektové systémy je dodnes považována za standard(!!!), ale já nejsem člověkem, kterému byste to měl vysvětlovat!\nMyslim, ze tady doslo k nedorozumeni, ja jsem prave myslel nejake napr. PLSQL API :) Tzn. co jen jde a dava to smysl, zpracovavat primo v DB a nahoru do aplikacni vrstvy vracet idealne jen vysledky a pokud to jen jde, neumoznovat primy pristup k tabulkam a pohledum.\nSamzorejme situaci, kdy zeshora budou volat v cyklu sluzbu misto jeji davkove verzy, tohle nevyresi, to je zas problem na jine urovni. Ale nekde zacit je potreba :)\nA jeste jeden muj postreh, nemuzu se obranit pocitu, ze spousta vyvojaru zcela nepochopila (a tedy nedocenila) rozdil/vyhodu RDBMS a tak je pouzivaji spis jako KV-store.\ndannak "spousta vyvojaru zcela nepochopila (a tedy nedocenila) rozdil/vyhodu RDBMS a tak je pouzivaji spis jako KV-store"\nMne bolo Nemcami vysvetlene ze pouzivaju tabulky bez vezieb preto ze ked bolo treba nieco v poprepajanej databaze zmenit tvrdo narazili tak napisali pravidlo ziadne vezby BODKA. Vezby su presunute do logiky programu. No co s nimi :-)\n7. 9. 2017 14:33\n...a pak se do tech dat sahne jinym kanalem a je po pravidlech/constraintech :/ jedna apka neco zapise a druha na tom pak vesele zhavaruje :)\nV okamžiku, kdy konzistenci řešíte mimo DB, tak je snad pochopitelné, že do té DB nebudete jebat kdekým ze všech stran, ale jen přes vrstvu, která to řeší.\n„Samzorejme situaci, kdy zeshora budou volat v cyklu sluzbu misto jeji davkove verzy, tohle nevyresi“\nNikde není napsáno, že nemůžete mít vedle operace pro jednotku i dávkovou operaci.\n8. 9. 2017 11:59\n„když to databáze umějí“ - Bavíme se tu o obchodních systémech, což jsou snad všechny objektové, ne relační.\n„správně napsaná aplikace nad SP bude vždy rychlejší“ - To nemusí být ale vůbec pravdou.\n„a (můj osobní názor) čitelnější“ - To už vůbec ne.\n„SP vás donutí do dekompozice“ - To jako do procedur? S možností vzájemné komunikace přes primitivní hodnoty, nebo až tabulky? Chcete tím stavět dekompozici do objektů na stejnou úroveň abstrakce?\n„Navíc SP vám umožní zabezpečení, které v aplikaci nikdy nemůžete dosáhnout.“ - :O To je jaké zabezpečení???\n„U Oracle PL/SQL se používá jeden z nejlepších a velice dobře navržených programovacích jazyků - je to založené na ADĚ“ - Dosahuje to alespoň abstrakce Javy? A které další RDB to ještě mají?\n8. 9. 2017 12:57\nTo je ta Vaše fixace na OOP (ta z Vás úplně tryská :)) - viz wiki ADA language. Úroveň abstrakce se musí držet rozumně - když píšete docházkový systém a použijete jej jako účetnictví, tak to nedopadá dobře. Postgres PL/pgSQL vychází z PL/SQL Oracle - DB2, a MySQL používají PSM - což je ansi SQL standard (funkčně podobné PL/SQL). Nejslabší je T-SQL u MS.\nŽádný z těchto jazyků není objektový! Což je logické - relační db nejsou objektové db.\nCo se týče zabezpečení - s uloženými procedurami mohu mít kontrolovaný přístup k citlivým údajům, nemusím se bát, že mi někdo obejde aplikaci, atd. Mohu omezit negativní impakt v případě kompromitování aplikačního účtu.\n"SB" je webový vývojář, používá ORM a nemá moc přehled z jiného světa. Tím ho nekritizuji, jen by bylo vhodné to zmínit, pokud se pletu, rád mě opraví.\nVeškerý tyhle objektové a ORM srandy končí třeba v momentě, kdy potřebuji obyčejný data masking, nechat to na doménové vrstvě není dobrý nápad a nepatří tam, řada úniků to jen dokazuje.\nPředstava, že v aplikaci modeluji byznys procesy mě skoro děsí, stejně tak, když potřebuji řádně rozložit náročné výpočty napříč clusterem, opět se to na aplikační úrovni moc řešit nedá. K tomu jsou určené procedury.\nV řadě případů to je ale kanón na vrabce a nehodí se k nasazení, jinde to je skoro nutnost a potřebuji tyhle enterprise warehousy. Článek příjemně popisuje jeden proces změny, vynikající, to ale neznamená, že správná volba je jen jedna databáze/technologie, naopak její správný výběr je důležitý, ne každá se na vše hodí.\nToho webového vývojáře si vyprošuju!\n11. 9. 2017 12:25\nTak tomu říkejte grafový systém, jak činím v nových příspěvcích, abych vás neiritoval. U (jednoduché) docházky se to snese, ale co u složitých systémů? Jak se u nich má graf k uložení do RDB? Jak se změní odpovědi na moje otázky?\nTo je možné, důsledkem ovšem je, že tím slučujete persistentní a aplikační vrstvu, takže, jak už se tu probíralo, umísťujete aplikační logiku do DB, místo abyste to (včetně bezpečnosti) nechal řešit ap. server.\nProč 3x??? Stačí jednou v aplikačním serveru, se kterým komunikují klienty. Řešení, kdy každý klient extra buší do DB, je proti tomu příliš závislé (DB, a to ještě konkrétní typ) a nepřizpůsobitelné (např. bez možnosti více zdrojů s distribuovanými transakcemi, ...).\n6. 9. 2017 9:51\nSkoro mezioborový článek, nabušený unikátními poznatky! Poklad.\nPavle, klobouk dolů, že jsi se podělil! Moc díky.\nMimochodem, cítím v tom velkou příležitost inspirovat vývoj pg fíčurkami z ora, protože tam určitě nějaké šikovnosti jsou.\nO které "šikovnosti" jde? Seriózně mě to zajímá. Díky.\n6. 9. 2017 20:43\nNevím, nejsem autor článku a neumím ora ani pg natolik dobře. Lituju, ale s touto flamewar nepomůžu.\n:) - některé zkušenosti/potřeby z tohoto projektu se promítly do nové verze Orafce, kde jsou částečně emulovány i některé systémové pohledy Oracle, což jsem původně nechtěl dělat - nicméně Orafce se opravdu primárně používá při portacích z Oracle a tato funkcionalita částečně pomůže.\nCo se týče SQL - tam se moc inspirovat nejde - pro Postgres (nikoliv pro EBD) je cíl ANSI SQL - a tam je hromada možností - temporální tabulky, lepší podpora JSONu, .. Některé užitečné vlastnosti, které má Oracle, a které by se hodily ať už při samotném použití Postgresu nebo při portaci jsou v ToDo (jelikož zatím se musí používat workaroundy). Tady primárně to jsou schéma variables a autonomní transakce - kdyby byly peníze na vývoj a čas, tak bych se do toho pustil - pracnost na schéma variables odhaduji na půl roku relativně intenzivního vývoje - a na to nejsou zdroje.\nInterní věci - tam se spíš přebírá z výzkumu - roky se dělá na hw akceleraci, poslední dva roky na integraci JITu. Tam je obecně velmi pomalý postup už při psaní prototypu (i výzkum není nějak daleko) - a výsledky nejsou zas až tak fascinující - pro běžný provoz zrychlení pár desítek procent nežene vývojáře k rychlejší akceptaci - přičemž reálně uživatelé preferují stabilitu a spolehlivost před novými vlastnostmi.\n7. 9. 2017 5:46\nChceš něco a nakonec ani nevíš co. Typický problém přispěvatelů do odborných fór (a ještě si pomůžeš zaklínadlem flameware)...\nChill out. :-) Obávám se, že jsi nepochopil můj původní příspěvek. Pavlovou odpovědí na něj jsem dostal mnohem víc, než jsem čekal, takže dobrý. Zmínku o flameware netřeba brát vážně.\nParadni clanek. Moc dekuji. Kdyby firmy, ktere plati za Oracle dali jenom polovinu toho co za to plati na vyvoj PostgeSQL, tak uz to mohlo byt uplne nekde jinde.\n6. 9. 2017 11:36\nNěco podobného jsem také řešil, ikdyž požadavek byl ještě silnější, a to udělat ze závislé (Informix) SQL aplikace plně platformově nezávislou aplikaci, tak aby mohla být provozována na různých RDBS. Měla podobný rozsah cca 200 tabulek, cca 2000 vložených procedur. Základem bylo vydefinovat povolené (ANSI SQL) struktury a techniky, které víceméně podporují všechny známe RDBS. Ano implicitní datové konverze jsou rozdílné skoro všude, daĺe jou rozdíly i v implicitních funkcích, a třeba v identitách, atd.. Následně se zavedl vlastní SQL meta kód a veškerý zdrojový kód se transformoval do tohoto meta kódu standardně uloženém ve verzovacím systému (GIT) s ostatním kódem. Následné se vytvoříly vlastní zavaděče, které tento meta kód transformovaly podle nasazeného RDBS. Vznikl tež nový validator-checker, který omezil programátory v tom, jaké konstrukce mohou v meta SQL používat, Teda bylo s tím docela dost práce to všechno předělat....přeji hodně štestí ve vašem snažení, budete ho potřebovat....\n7. 9. 2017 14:56\nCo budete prosím dělat, až přibude další RDB, která má ještě menší, nebo jiné možnosti, než ty všechny dosavadní, „nezávislé“ databáze?\nDekuji z skvely clanek. Koukal jsem na ten ora2pg a ono to ani neni moc velke. Par tisic radku v Perlu. Dost me prekvapilo kolik prace to dokaze udelat. Cas od casu se me nekdo zepta na podobny problem, a zda se ze vznikaji komercni produkty, ktere resi podobny problem, tyto produkty ale jdou narocnejsi cestou, preparsuji PL/SQL, prevedou ho na AST a pak ze stromu generuji jiny dialekt SQL. A tady si trochu prihreju polivcicku, tohle je IMHO nejlepsi open-source parser PL/SQL jaky je k dispozici https://github.com/ibre5041/plsql-parser, adresar tests navic obsahuje dost hnusne corner-case pripady.\nPodle slov autora byl Ora2pg rychlý hack, kdy šlo hlavně o to, jednoduše zmigrovat strukturu tabulek a data z Oracle do Postgresu - a šlo o to to udělat co nejjednodušeji a co nejrychleji. Potom se na to nabalovaly další věci a více-méně pro samotného autora šokující, co všechno se dá udělat sadou regulárů.\nReguláry fungují, ale není to kdoví jak rychlé - 200K řádků se převádí cca 100 minut (pořád je to použitelné). Tipnul bych si, že pokud by se použilo AST, tak by odpovídající migrace trvala 10 minut. Hlavně by asi kód Ora2pg byl výrazně čitelnější. To AST v plánu je - ale zatím autor nenarazil na limity stávajícího řešení, takže chce dokud to jde, pokračovat ve stávajícím kódu - a privátně si buduje testovací bázi, vůči které pak bude psát Ora2pg 2, která už bude na AST. Nevím, jestli to vyjde, ale předběžně se bavím s Gillesem, že by přijel na P2D2 2018 příští rok.\nmusim se priznat, ze to hlavni , co jsem si z clanku odnesl, je poznatek, ze do nejake takove migrace je asi nejlepsi se nepoustet.\nPro tuhle aplikaci je to jediná šance. Oracle, kdysi poskytoval malým vývojářům velice zajímavé slevy, takže jejich produkty byly i nad Oraclem konkurence schopné. Ochota Oracle tyto slevy poskytovat výrazně klesá a bez nich je ten produkt neprodejný. Stejně tak rostou náklady na licence - produkt je určený pro prostředí, kde nejsou velké marže, dneska už je i docela konkurence a cena hraje primární roli. Takže buďto migrace do Postgresu nebo konec - a autoři mají ještě 15 let do důchodu. Cenovou alternativou by byla migrace do Oracle cloudu, ale to je nestravitelné pro významné uživatele té aplikace.\nMigrace by byla výrazně jednodušší, kdyby ta aplikace byla čistě napsaná - pak je to skoro trivka, a dá se provést za několik málo týdnů i v takovém rozsahu. Teď se tam půl roku dělá refaktoring, který se předchozích 15 let nikdy nedělal.\nmuj prispevek mel byt spis takovym obdivem, ze se nekdo do takovych akci pousti. Jak popisujete v clanku, je v tom spousta zaludnosti a nebezpeci ciha na kazdem kroku. Projektovy manager neceho takovehy bych fakt byt nechtel.\nNa druhe strane obdivuji, ze se patrne podarilo firme vysvetlit, ze to bude adekvatni dobu trvat a taky stat. Nemam predstavu co Oracle po tech zakaznikach dneska chce, ale kdyz jdou zakaznici do takovych migraci, tak to musi byt asi sila.\nTaky chapu, ze ta migrace je i sance vylepsit firemni procesy a vubec IT inrastrukturu. Presto mam pocit, ze se nejde nejak dal ve vyvoji, jen se vymeni jeden DB.stroj za jiny ale paradigma zustava.Jak i zde v diskuzi zazniva, pocituji zvyseny tlak na moznost, pouzivat aplikaci pod vice databazemi. Jak spravne upozornujete, je to problem a jestlize napasovana aplikace bezela 15 let pod Oracle a ted pobezi 15 let pod Pg tak neni co resit. My mame u nas ve firme situaci , ze standardiziovana aplikace by mela bezet pod 'libovolnou' databazi a my se snazime to resit jako SAP s HANA => investovat do HW :-)\nJe to malá firma, která má jediný produkt a nemá moc alternativ - na druhou stranu tam není dosazený management - firmu si řídí vlastníci, kteří jsou docela v obraze, a technicky na tom jsou také dobře - jsou motivováni tu migraci udělat. Ve větších korporacích je to něco úplně jiného - hromada řečí - a viditelný progres je za tři, čtyři roky - není to značka, která je jim známá, a ošahání si nové (pro ně neznámé) databáze trvá - není to problém jenom managementu, ale i adminů, vývojářů. Pokud to není Oracle, tak je to pro ně podezřelé - ale už je tu pár podařených projektů v oblastech, kde by mne před 5 roky nenapadlo, že by se Pg mohl nasadit.\n6. 9. 2017 14:05\nJa..... (neregistrovaný) 84.16.51.---\nA čo tak popisať ako je riešený COMMIT, rollback to savepoint, autonomna transakcia....\nNiekde nejaky kravatak napisal ze je to izy... ved naco je rollback ved exception samo urobi rollback.. Inaksie este asi 100 dalsich zaujimavosti popisanych vlastnosti.. Napr. retazec NULL a "" nie je to iste, ale v oracle je to nulll, to znamená prekopat celu logiku....\n7. 9. 2017 5:39\nROLLBACKy, SAVEPOINTy jsou v Postgresu implicitní - dané strukturou - většinou stačí přizpůsobit blokovou strukturu kódu a pak v Postgresu je zakomentovat (je to v ToDo Ora2pg). COMMIT je v Postgresu také implicitní - v podstatě je to aplikační záležitost - pokud nedojde k chybě, tak při autocommitu se se commituje automaticky.\nZáleží na důvodu proč v kódu používáte COMMIT - ve většině případů jej stačí pro migraci do Postgresu opět zakomentovat (Ora2pg to při migraci může udělat). V aplikaci, kterou jsem migroval se pouze v jediném případě nějak aktivně používal opakovaný COMMIT v procedůře - a bylo to z důvodu pádů příliš velkých transakcí na Oracle - což v Postgresu není problém, takže vnitřní COMMIT v proceduře jsme v Postgresu mohli ignorovat.\nOra2pg umí vyřešit i bezpečné porovnání na prázdný řetězec - nicméně výsledný výraz je výrazně delší, takže je jednoduší opravit kód na Oracle, tak aby se mohl 1:1 použít i na Postgresu - tj na Oracle nepoužívat prázdné řetězce, ale pouze NULL (v IF a pro jiné datové typy než je varchar). Je to asi masivní změna, ale dá se to udělat hromadně - takže i při statisících řádcích je to práce na pár pracovních dnů.\nNetvrdím, že migrace aplikace, která často používá silně Oraclovské obraty je na lusknutí prstu - ale je realizovatelná - a kromě toho, že se připraví port do Pg, tak se i hlavně zásadně pročistí kód v PL/SQL.\nPokud by kód v PL/SQL (Oracle) byl napsaný podle moderních best practicies, tak pak migrace je docela jednoduchá. Když se použivají deprecated výrazy, obsolete funkce, tak je to výrazně pracnější - prvně je potřeba modernizovat (vyčistit) kód v PL/SQL a pak poté provést migraci.\nV některých případech to může být pro uživatele, vývojáře příliš drahé - pak je alternativou EDB, kde jsou alespoň poloviční a nižší licenční náklady a je tam vrstva, která emuluje Oracle, anebo aplikace musí dožít na Oracle.\n11. 9. 2017 15:58\nvasek (neregistrovaný) 193.29.81.---\n"pak je alternativou EDB"\nNevím, jak se situace změnila, ale naše firma si před asi 6 roky myslela to samé, ale EDB byla tak nespolehlivá a plná chyb (a stejne neuměla vse co oracle a přechod byl velmi bolestivý), že ten přechod rovnou na čistý postgres (na který se nakonec stejně přešlo) by bývala byla lepší varianta.\n11. 9. 2017 17:01\nEDB je v jádru Postgres - vrstva kompatibility s Oraclem není příliš tlustá - úplně emulovat Oracle nelze - ale nejčastější balíčky a PL/SQL emulují v zásadě dobře. Určitě je tam nějaký posun. Určitě ne každá aplikace poběží bez úprav na EDB, na druhou stranu těch úprav nemusí být zase až tak hodně.\nObecně platí pravidlo, že by funkce neměly obalovat jednoduché SQL příkazy. Zvlášť, pokud se tyto funkce volají z komplikovanějších SELECTů. Jednak se tím snižuje prostor pro optimalizaci (SQL se uvnitř funkce optimalizuje izolovaně). Hlavně ale dochází ke generování a počítání velkého množství zanořených SQL příkazů, a to má dost velkou režii\nJeste dodam jeden postreh. V SQL se neda dost dobre strukturovane programovat. A kdo chce za kazdou cenu nejak sdilet kod, tak prave vklada SQL do funkci, ktere nasledne vola z jineho SQL. V Postgre s tim az tak velky problem neni, ale v Oracle to rekurzivni SQL pouziva jine SCN a vidi i data, ktere nadrazene SQL jeste videt nemuze (phantom read). Takze nejenze je to pomale, ale navic to neni logicky spravne, a ve vice-uzivatelskem prostredi vam takovy dotaz muze vratit totalni bramboracku.\nTo je dobrá připomínka - díky za ní.\nV SQL prostředí ten nástroj, který bych měl používat proti duplikování kódu nejsou funkce! K tomu slouží pohledy - což hromada programátorů nepochopila -svoje znalosti přenášely do prostředí SP 1:1 z klasického programování - případně z Cobolu, FoxPro, kde pohledy neexistovaly - jde o nesprávné uchopení technologie - navíc v tomto případě s potenciálně fatálními důsledky.\nmam desktop aplikaciu ktora bezi na x pocitacoch.\ny ludi pozera na rovnake dat.\nniekto z nich updatne hodnotu ktora sa ulozi do DB a ostatnym sa behom milisekund (<100ms) updatne vysledok vypoctu ktory je iniciovany zadanou hodnotou a zbehne na backende.\nje toto riesitelne cisto pomocou business logic na DB? (vypocet je celkom komplexny a vstupuje do toho viacero dat z DB)\n6. 9. 2017 19:02\nJde o to, jestli je úloha matematicky komplexní nebo datově komplexní - pokud generuje větší množství dotazů, případně dochází k přesunu většího objemu dat mezi klientem a serverem, pak mají uložené procedury smysl - cílem je minimalizovat komunikaci mezi databází a klientem - a vytvořit sémantické API pro klienta.\nJinak uložené procedury už dnes běžně umí notifikovat klienta - v případě změn dat, aby provedl refresh.\n7. 9. 2017 20:48\nSry za trochu zneužití této diskuse. Ale jsou tu Ora i Pg experti a mluví se tu o výkonu a Pavel nyní zmiňuje čekání na IO.\nMůžete pls naznačit své zkušenosti, jak zatěžovaným databázím pomůže jejich umístění na SSD disky?\nNemam vylozene zkusenosti ze by nektery ze zakazniku pouzival primo SSD, ale pokud napriklad ulozite redo logy/archived logy na SSD, tak log switch bude znatelne rychlejsi a tudiz se zvedne i celkova vykonost databaze. Pokud se na SSD daji data (tady bych se bal o zivotnost tech SSD), tak je mozne, ze cteni a zapis techto dat bude take zretelne rychlejsi. Oracle u sve Exadaty pouzive neco ve smyslu Smart Flash Cache, ktera vyuziva flash pameti.\npoužití ssd pomůže k výkonosti zejména u krátkých dotazů a vyšší konkurenci (bráno obecně), ale nespravíš tím špatný návrh databáze nebo neoptimalizované dotazy. Pokud ti to brzí velké množství locků, ssd tomu pomůže jen částečně.\nŽivotnost ssd je dnes snad lepší než u plotnových disků, ale nesmíš kupovat ty věci z alzy, hlavně se chce zaměřit na SLC, ostatní mají životnost mnohem horší. Vykašli se na disky do sas/sata, tam není velký výkonnostní rozdíl, rovnou se zaměř na nvme do pcie 4x či rovnou 8x.\nŘada velkých databázích rovnou používá ssd, zmiňovaná exadata, netezza, teradata atd.\nV našem ERP to zrychlilo MRP ze čtyř hodin na tři. A report výroby to zrychlilo z jedné minuty na pět sekund. Takže asi jak co, bude záležet na tom, co je vlastně ten bottleneck, zda počet IO nebo seek (je jich moc vs. trvají dlouho), přenosová rychlost atd. Jo a původně tam byl 15K 6G SAS disk. Takže možná jen to SSD nemělo takový náskok.\n8. 9. 2017 0:17\nNazdar chlapci prisel jsem se na vas podivat, autor mne zklamal misto aby delal karierni postup a vydelaval poradne prachy jak jsem mu pred 5 lety navrhoval, tak pokracuje v aktivitach na kterych se nedaji vydelat penize. Proc cilit na zakazniky kteri neutahnou ani licenci Oracle? Jak pak mohou zaplatit za kvalitne nacenene IT sluzby? Je potreba se v kariere posunout dal a hry o drobne prenechat malym detem. Doufam ze si spolu rozumime v tom ze penize jsou pozitivni vec.\nPostgresql je minoritni databaze, neznam zadneho z nasich zakazniku ktery by ji pouzival v produkci. MySQL pouzivaji protoze to podporuje Oracle, ma to kvalitne zmaklou replikaci a clustering, Je to levne (uspori se 90% nakladu oproti Oracle).\nJe tu nejaka vetsi a solidni firma co by delala podporu a poskytovala zaruky na PostgreSQL? Je tu EDB ale ti nejsou ochotni verejne sdelit ceny, kazdou delaji individualne a fixaci ceny nabizi jen na 3 roky. Jednat s podobnymi spolecnostmi se mi uz mnohokrat silne nevyplatilo, protoze mi nabidli pokracovani smlouvy za podstatne vyssi (i 10x cenu) kdyz zjistili jaky delame obrat. Prachy jsem jim stejne nikdy nedal a premigroval.\nZe stored procedur jsem byl nadsen v 90 letech, tehdy jsme je delali v embedded SQLC, dneska je pouzivame jen z duvodu vykonu po dukladne performace analyze - je v nich asi 1% logiky. Tohle neplati pro mainframy, tam se v psane v COBOLu pouzivaji vice a i to je jeden z duvodu proc vyvoj na mainframech je zhruba 20x drazsi.\n8. 9. 2017 5:04\nTy pořádné peníze mi nestojí za to, abych byl, víc než chci, namočený v korporátu. Řeší se tam problémy, jejíž řešení mne nebaví, a na to, aby člověk mohl být kreativní, tak bych musel být asi v Oracle, nebo v MS - jinak se blíž člověk k technologii nedostane. Co jsem slyšel o Oracle, tak tam bych asi určitě dlouho nevydržel. Takže tak.\nTo, že Vaši zákazníci nepoužívají Postgres, to neznamená, že by byl Postgres minoritní db. Díky BSD licenci se na ní nedají moc vydělat peníze (ohledně licencí a supportu) - takže ve spojitosti s Vašemi názory mne to vůbec nepřekvapuje. Navíc, pokud někdo používá db jen jako storage, tak MySQL může být optimální.\nSupport Postgresu - RedHat, v ČR Elostech, globálně 2nd quadrant, PostgreSQL Pro. Když máte tolik peněz, tak si zaplaťte dva - tři top vývojáře Postgresu, budete mít špičkovou podporu z první ruky - dělá to tak hromada firem.\nNebrec ze se ti nelibi makat pro korporaci. Zrovna tobe jsem nabizel ze ti pomuzu se zalozenim startupu nabizej jsem ti 30% a 2 mega. V zivote neni mnoho momentu ktere dokazi zmenit tvuj zivot - tohle byl jeden z nich. Bylo to v dobe kdy se IBM snazilo procpat svym zakaznikum PGSQL, udelalo prirucky, skoleni, podporu migraci - no ukazalo se ze to byl fail a jejich zakaznici na to neslysi.\nTo byl dalsi z dukazu ze se na PGSQL vydelat neda. Na postgresu zdechlo uz neuveritelne mnozstvi i velkych firem. To je jako podnikat na pousti kde se vali kosti. Zdechnula Great Bridge, Sun, IBM. Je videt ze o tento produkt nemaji zakaznici zajem. On to totiz neni produkt protoze nema veci co cini produkt produktem, je to technologie. Technologie se prodavaji licencovanim, coz nejde kdyz je technologie k dispozici bezplatne. Jedina zivotoschopna firma delajici PGSQL je EDB protoze v ni ma IBM zainvestovano 20 mega a postara se aby nepadla.\nPodivej se na FreeBSD. Tuhle technologii pouziva rada veci - ibm, juniper, cisco, playstation, nitendo, apple. Je to spatna technologie? Evidentne ne. Da se vydelat na FreeBSD jako na produktu? Ne. Jediny zpusob jak na ni neco vydelat je to vzit a postavit si neco nad tim a to pak prodavat. Technologie je zdarma, usetri se za licencni poplatky.\nTo co ty nabizis za reseni - zamestnat vyvojare jako support jen dokazuje jak je maly tenhle trh. Tech vyvojaru moc nebude, pro support potrebujes aspon 3. Na kolik firem by se timhle zpusobem dostalo? A kolik vyvojaru je ochotno delat misto programovani 247 support?\nDival jsem se na 2nd quadrant a na PGSQL pro. Taky nemaji verejne ceny, chteji aby zakaznik s nima navazal vztah a pak mu sdelili jejich tajnou cenu. Kdyz nevi za kolik vlastne prodavat, jak jim mam verit ze se v byznisu udrzi. Pocet lidi co by si koupili PGSQL je maly a oni jej jeste snizi tim ze vyzaduji tuhle ceremonii s navazovanim vztahu. Pletou si byznis s manzelstvim, byznis je o cislech. Vsechny 3 firmy maji svuj fork PGSQL ktery se snazi prodat jako svuj hlavni produkt, koupit si fork udelany malou firmou a vyrazit s tim do produkce je jeste vetsi riziko nez vyrazit se stock pgsql - co kdyz firmicka krachne? To budeme prepisovat aplikaci? Proc jit do tohodle rizika kdyz nemusime?\nTed si vem ten tvuj pripad. Mas zakazniky co nechteji platit za Oracle a ani za EDB ktera je levnejsi a migrace by byla mnohem snadnejsi. Evidentne jim nejsou schopni prodat databazi s nenulovou cenou jako soucast reseni. Cil je nejak to doklepat dalsich 15 let. Nikdy nevydelas dostatek penez abys mel na investice do rozvoje protoze tvy zakaznici penize nemaji. Takze pracujes za naklady diky neschopnemu managementu ktery nema koule na to poslat neperspektivni projekt k zemi a jit delat neco pro lidi kteri maji penize na zaplaceni.\nJa proste nevidim zadnou pozitivni vec ktera by mne presvedcila ze mam do PGSQL jit. Napis mne 3 duvody ktere mne podle tebe presvedci ze je to nejlepsi mozna volba. Pro mne je to hobby.\n9. 9. 2017 22:38\nAsi vůbec netušíte, o čem tu píšu a co a proč dělám - opravdu 30% a 2MB není nic, co by mně oslovilo.\nBerte to tak, že Postgres je životní styl, jako Linux, nebo BSD .. buďto vám sedne a baví vás v něm psát, používat jej, nebo ne. Je to sw, se kterým můžete věci dělat jednoduše a po svém - a dobře a slušně - protože máte možnost se podívat na to, jak je napsaný, máte možnost se bavit s vývojáři, máte možnost se podílet na vývoji - a to aktivně nebo pasivně. Nemusíte řešit komplikované licence, a nemusíte biflovat checklisty a pohled do zdrojáku, možnost si něco odladit nebo se zeptat autorů je za desítky stránek dokumentace, takže nemusíte ani biflovat mraky dokumentace. Prostě s Pg je život jednoduchý - což je to, co mi vyhovuje. Nemusím se bavit s obchodníkama - bavím se s inženýrama.\nJak IBM, tak další korporace Pg používají - jedním z největších uživatelů je Microsoft nebo Cisco. Pro ně je Pg dostatečně dobrá databáze. Do jisté míry Postgres je alternativa - je to projekt, který nemůže krachnout - je to alternativa ke korporátnímu způsobu uvažování a chování - a buďto jste zaháčkovaný v korporátu a asi těžko budete hledat motivaci pro použití Postgresu, jelikož na licencích fakt nenaděláte těžký prachy nebo hledáte alternativy - takovou alternativou, přičemž ale technicky na úrovni (každý si může zkontrolovat kód), je Postgres (v oblasti SQL relačních DB).\n10. 9. 2017 7:34\nMě by teda dva miliony bitcoinů oslovily :D\nNeexistuje dobrá nebo špatná databáze - databáze je pouze dobrá nebo špatná pro daný úkol/úlohu.\nať jsem v databázích pořád junior, mám stejný názor a tyhle diskuze mi přidají občas dost mimo. Přesvědčovat někoho o tom, že jiná db je mnohem vhodnější ač neznám všechny okolnosti a důvody použití původní je střílení na slepo.\n9. 9. 2017 13:32\nJe to [MySQL] levne (uspori se 90% nakladu oproti Oracle).\nTo jako vážně nějaký váš zákazník uvažoval o Oracle DB, a pak místo toho pořídil MySQL? To je jak porovnávat formuli jedna s tříkolkou. „Ano, uvažovali jsme pro naší tříletou Matyldu o monopostu F1, ale pak jsme si řekli, že ušetříme, a pořídili jsme jí tříkolku.“\n9. 9. 2017 17:18\nJo byla to zdravotni pojistovna, asi 35M klientu. Pri jednom z upgradu sw co jsme jim delali se jednalo o koupi noveho HW (ten stary mel 10 let, fungoval spolehlive) a manageri zacali strasne knourat jak nemaji prachy na provoz a ze to chteji co nejlevnejsi a ze jsme podle jejich nazoru drazi. Tak se rozhodli ze misto Oracle chteji MySQL a misto IBM RISC chteji Windows Dell PowerEdge cluster. Ja jim nato ze si musi udelat load testy a smlouvu o podporu HW, OS, Database s garanci. Tvrdili ze to vsechno maji, no tak dobre, tak jsme u nas prehodili ORM na MySQL a zkouseli zda to jde, ono to neslo protoze MySQL melo bugy, ale kdyz jsme upgradovali MySQL na posledni verzi tak unit testy prosly bez problemu. Sice se jim nelibilo ze nebudeme pouzivat tu verzi MySQL co tam nainstaloval admin a na kterou maji podporu, ale kdyz videli ze to opravdu jinak nejde tak na to kyvli.\nVzhledem k tomu ze na teto platforme negarantujeme nic z provozu, jen to ze projdou nase testy, tak jsme s nimi v kontaktu uz nebyli. Prisel jsem na pobocku jako client - system nejel pry uz 2 dny, pak jsem prisel za par mesicu to jim slo, na dalsi navsteve jim to opet nejelo. Tak jsem zmenil pojistovnu. Pak uz od nas nechteli ani SW zdali jsme se jim drazi.\nPred 3 lety jsem se nahodou potkal s klukem ktery vedl tym co tehle pojistovne delal sw servis. Brecel jaci jsou to drzgresle ze si nemuze dovolit koupit ani sw na load testing za 15000 USD protoze z tech penez co plati sotva zaplati lidi kteri makaji vyhradne na open source sw.\nPritom jsem zjistil ze jednak pojistovna pouziva nas SW bez licence, a chlapec ma k dispozici ostra data pacientu. Takze jsem zazaloval oba dva. Chlapec i pojistovna dostali pokutu za nelegalni pouzivani SW a pojistovna i chlapec dostali basu za neopravnenou manipulaci s daty pacientu.\nPojistovna se dostala do problemu a investor tam musel nasypat dalsi prachy, tak si se mnou dal schuzku zda bychom to neudelali jako predtim. Rekl jsem si o 50 Mega USD za 10 let - blackbox reseni vcetne HW, pojistek etc. To se mu zdalo moc a vykopnul mne s nadavkama. Za par dni volal ze by chtel schuzku - ja jsem mu rekl ze na zadnou nejdu, neumi se chovat a ze moji nabidku kterou nechtel jsem stahl. Nechtel moje reseni a tak ho taky nema - v cem je tedy problem. Rikal ze si nechal udelat konkurecni nabidku a tam chteli 12 mega rocne, tak jsem mu to nakonec dal za 10 mega rocne s tim ze v cene budou i prazdniny pro management no a vzal to.\nPohádkář jsi pěkný, ale občas se necháš unést a píšeš nesmysly podle kterých je poznat, že nás taháš za fusekli. Trochu na tom ještě zapracuj a budeš pohádkářská jednička!


středa 24. 10. 2007,\nGates potvrdil záměr USA zapojit Rusko do budování protiraketového systému\nSněmovna přes odpor opozice schválila základní parametry státního rozpočtu\nJulínek prý nemocnice rušit nebude, chystá ale jejich sjednocování do větších celků\nJedna židovská organizace svolává sportovce a vojáky na pomoc proti neonacistům\nLužný bude dál usilovat o funkci ministra školství, ačkoliv si ho Topolánek nepřeje\nElektronizace justice by měla být podle ministra Pospíšila hotova do roku 2010\nNěkdejší pohraničníci dostali za zavlečení emigranta do ČSSR podmínku\nČeši by v referendu podpořili uspořádání olympiády, tvrdí STEM\nPočasí v Praze: zataženo s přeháňkami, chladno\nÚčet organizace byl neoprávněně obstaven soudem.\nDovolujeme si informovat veřejnost o aktuálním postupu žalobce Tomáše Paclíka ve věci sporu s nevládní organizací Růžový panter. Ačkoli organizace Růžový panter zaslala k dnešnímu dni žalobci Tomáši Paclíkovi již 90.000 Kč z povinného plnění uloženého soudem, Tomáš Paclík vůbec neinformoval okresní soud v Berouně o tomto plnění a dnes tento soud uvalil na účet organizace exekuci V PLNÉ VÝŠI povinného plnění, tedy Kč 145.350,-, zřejmě včetně nákladů exekuce. Nyní organizace musí vyčkat do doby, než si žalobce převezme poštu okresního soudu. Poté organizace bude o tomto kroku oficiálně informována příslušným soudem a teprve poté může podniknout příslušné právní kroky, tedy podat návrh na zastavení exekuce a odvolání ve věci nákladů řízení. Co se týče dalšího plnění, na věci se v zásadě nic nemění, pouze nyní organizace nemůže zasílat žalobci Paclíkovi splátky, a to až do dořešení exekuce. Až soud účet opět uvolní, bude doplacena žalobci pouze taková částka, na kterou má z rozhodnutí soudu nárok. Proto prosíme veřejnost, aby nepřestala zasílat na tento účet své příspěvky určené žalobci Paclíkovi. Organizace nyní nemůže s účtem svobodně nakládat, nemůže tedy např. hradit ani telefonní účty. O vývoji situace bude organizace veřejnost průběžně informovat. Děkujeme všem, kterým není tato událost lhostejná.\nVíce informací o soudním sporu na www.ruzovypanter.cz\nNPO Růžový panter\nČESKÝ POLITICKÝ CIRKUS: Selhání státu\nK čemu máme stát? K tomu, aby vykonával ty činnosti, které nemůže dělat jednotlivec. Koupit dítěti pastelky dokáže jednotlivec. Stavět dálnici nedokáže jednotlivec. Koupit si krabičku aspirinu dokáže jednotlivec. Hájit se proti neonacistům nedokáže jednotlivec.\nJelikož je u nás vše na hlavu postavené, stát raději rozdává peníze z veřejných prostředků, tedy z těch peněz, které vyždíme z úzké skupiny subjektů tvrdě pracujících a podnikajících ve stále užších mantinelech státní šikany, a to co by dělat měl nedělá vůbec nebo špatně.\nTakže to došlo tak daleko, že na chystaná útok neonacistů svolávají pražští Židé na pomoc cosi jako domobranu, sportovce a vojáky. Nemohou si být jisti, že je tento stát ochrání před oslavou Křišťálové noci, jedné z nejhnusnějších událostí v dějinách lidstva.\nJe to strašná hanba, strašné pomyšlení.\nBohužel je to logické, v zemi, kde každý pátý člověk podporuje komunisty, kde bratři Mašínové jsou oficiálně pokládáni za zločince a kde pohraničníci, kteří na německém území postřelili našeho občana a zavlekli ho do komunistického lágru dostali podmínečný trest s odkladem na tři roky.\nPSÍ PŘÍHODY: Na návštěvě u Barta\nBart oslavil skoro před měsícem dvanácté narozeniny - před měsícem, jak rychle ten čas běží! Jak se mu daří, často slyším tuhle otázku. Starému pánovi se nikdy nedaří nějak moc dobře - pokud platí psí počty, pak by mu mělo být lidských 84 let. Zlobí ho nohy, už neuběhne ani zdaleka to co dřív a na nějaké společné výlety do Prokopského údolí, jak jsme je s ním a Iris dělali dřív, na ty je třeba zapomenout.\nZajel jsme s Iris autem až na pozemek a pak teprve Iris vypustil. Bart nás už čekal. Nejdřív uvítal mě, oslintal, na co dosáhl. Pak jsem vystoupil a šel otevřít Irdě. Bart šel se mnou a vítal ji. Stará náklonnost přetrvala. Být to jiný pes, Iris by ho při otevření dveří oslovila hromovým (v rámci její hromovitosti) vrrrr. S Bartem se ale uvítala důstojně.\nPak jsme šli společně nahoru. Dostal jsem od Ireny kafe a sušenky a seděli jsme u stolu povídali si a pod stolem to bylo pěkně poskládáno: Iris, Bart a Dominika.\nNebude to tak vždycky, z mnoha důvodů. Ale bylo to milé a ta vzpomínka zůstane.\nTaky ne navždycky.


5 hráčů, kteří by mohli nahradit Lingarda na pozici číslo 10 | PremierLeague.cz\nBrarilec Pereira svým stylem hry velmi připomíná Jesseho Lingarda, opět tu ale hraje rozdíl kvalita, co se týče rozehrávky.\nPereira je rovněž technicky velmi silný na balónu a je to on, kdo by mohl být řídícím motorem Manchesteru.\nSolksjaer proti Chelsea využil Brazilce na pozici pravého křídla a ačkoli rodák z Duffela dokáže solidně zahrát na obou postech, tak pozice ve středu by mu přeci jen vzhledem k jeho propozicím měla vyhovovat více.\nO pozici podhrotového hráče usiluje i Andreas Pereira.\nPereira je pověstný rychlýma nohama a neméně tak velkou houževnatostí na trávníku, která z něj dělá dobrou volbu na celou dobu propíranou pozici ofenzivního záložníka.\nS jeho přemýšlením a schopností rychle vyřešit situaci dokáže Andreas jednou přihrávkou úplně zmást jindy výborně formovanou obranu.\nCizí mu není ani střílení branek, Brazilec má výbornou ránu, po níž ve většině případů musí být gólman ve velkém pozoru.\nSázka na teprve osmnáctiletého mladíčka z akademie by se mohla zdát jako velký risk, avšak Gomes ukazuje, že i v tomto věku už může být platným hráčem minimálně širšího výběru A mužstva.\nDostane talentovaný fotbalista v letošní sezóně šanci ukázat svůj potenciál?\nGomes předváděl v přípravě velmi působivé výkony, jimiž se dokonale revanžoval trenérovi za důvěru v jeho nasazení.\nV dosavadních dvou ligových kolech ale Angel nebyl ani na střídačce, což se klidně může změnit už o víkendu proti Crystal Palace.\nOsmnáctiletý teenager v přípravě zaujal gólem do sítě Spurs, když si parádně narazil s Matou a poté z velkého úhlu technickou střelou prostřelil Gazzanigu a rozhodl o vítězství Manchesteru United 2:1.\nI navzdory nízkému věku se Gomes vůbec nebojí hrát s balónem nebo zkoušet překvapit protivníka nečekaným řešením. Angličan navíc disponuje vysokou rychlostí, jež se dokonale hodí do Soslkjaerova pojetí hry.\nPokud v průběhu sezóny dostane Gomes šanci, mohl by většinu odborníků překvapit svou tvůrčí rolí.\nPřesouváme se ke zkušenému borci, jímž není nikdo jiný, než Juan Mata. Španěl je možná vůbec tou nejlepší možnou volbou pro Lingardovu pozici, neboť v prostoru za hrotovým útočníkem sehrál již nespočet utkání, problém ale tkví v rychlosti, v níž 170 centimetrů vysoký fotbalista za svými konkurenty podstatně zaostává.\nŠanci by si rozhodně zasloužil i Juan Mata.\nNorský lodivod, podobně jaku v případě Pereiry, používá Matu spíše na pravém křídle, kde se ale Španěl jako doma rozhodně necítí. Zajímavou variantou může být prohození Lingarda s Matou, v tom případě by oba hráči hráli na svých preferovaných pozicích.\nŠpanělův první dotek s balónem bývá v devadesáti procentech bezchybný, přehledem ve hře a rozehrávkou se může klidně řadit mezi nejlepší fotbalisty světa.\nMata rovněž může přinést potřebné zkušenosti do jinak velmi mladého kádru Rudých ďáblů. Manažer je ale zřejmě zatím jiného názoru, neboť šikovnému Španělovi v úvodních dvou kolech dopřál dohromady pouze slabých patnáct minut.\nTohoto Francouze není třeba více představovat. Pogba by rovněž určitě mohl zastoupit Lingarda na pozici číslo 10, avšak v současné době hraje Pogba hlouběji v poli, i přesto ukazuje svůj fantastický přehled ve hře v plné kráse.\nPogba je na pozici Lingarda tou nejlepší volbou, Rudí ďáblové však musí počkat na uzdravení Freda.\nPaul se výraznou měrou podílel na debaklu Chelsea, když se blýskl dvěma asistencemi, zvláště dlouhý nákop za obranu na Rashforda stojí za zmínku.\nMinulý víkend ovšem v klíčové chvíli selhal, za vyrovnaného stavu proti Vlkům neproměnil penaltu a stav se už po zbytek zápasu nezměnil.\nVe vytaženější pozici Pogba může naplno prokázat své technické dovednosti a přehled ve hře, problém by však nastal na jím opuštěné pozici, kam by se vedle McTominaye musel postavit v poslední době v neúplně dobré formě hrající Matić.\nNorský lodivod tedy nejspíše ještě počká na plné uzdravení středopolaře Freda a až poté začne uvažovat o vysunutí francouzské megahvězdy.


Lanovka na Větruši se zastavila, její údržba potrvá až do víkendu - Ústecký deník\nLanovka na Větruši se zastavila, její údržba potrvá až do víkendu\nÚstí nad Labem - Turisté se od pondělí opět nesvezou lanovou dráhou z ústeckého obchodního centra Forum na zámeček Větruše. Ústecký dopravní podnik její provoz na pět dní přerušil, protože lanovka musí projít další pravidelnou údržbou. Rozjet by se měla v sobotu 8. listopadu.\n„Je to plánovaná odstávka. Po celoročním provozu musíme lanovku připravit na zimu. Přijeli kvůli tomu i technici ze Švýcarska," uvedl mluvčí František Chlada.\nLanovka stojí kvůli údržbě pravidelně i každé první pondělí v měsíci.


Domů / Nábytek ve skandinávském stylu\nInspirujte se naší nabídkou obývacích stěn ze sérií LOVELI, NORDI, OSLO a PANAMA a seskládejte si svůj nový obývací pokoj z mnoha systémových dílů podle vlastních představ!\nVybavit si tak můžete interiér své ložnice z naší kolekce LOVELI a kombinovat s šatní skříní PANAMA či NORDI. Pozornost věnujte také našim jídelnám ze systémového nábytku, které můžete opět ladit do severského stylu přímo ze série OSLO.\nSeversky laděný obývací pokoj může zdobit rohová sedací souprava MALMÖ. Pozadu nezůstáváme ani v nábytku do předsíně, kterou vybavíte ve svěžím stylu z kolekce PANAMA.


Vezuelský prezident Maduro chce využít zmatku v opozici a vyhrát předčasné volby | Plus\nOpozici tak brzký termín volby hlavy státu překvapil. Už několik týdnů mezi ní a venezuelskou vládou probíhají rozhovory v Dominikánské republice, i když zatím bez výsledku. Opozice v jednání usiluje o záruky, že hlasování bude svobodné a poctivé a budou na něj moci dohlížet zahraniční pozorovatelé. Ministři zahraničí čtrnácti převážně konzervativních zemí Latinské Ameriky vyhlášení předčasných prezidentských voleb kritizovali a prohlásili, že za současných podmínek je možnost důvěryhodného volebního procesu ve Venezuele vyloučena.\nHospodářství v krizi\nDubnové hlasování o hlavě státu bude už čtvrtými volbami od loňského července, kdy se funkce ujalo Ústavodárné shromáždění. Jeho tehdejší zřízení odsoudilo celé mezinárodní společenství jako otevřené uchvácení moci Madurem. Podle venezuelské ústavy musí nový šestiletý prezidentský mandát začít až v lednu 2019. Volby se proto obvykle konají až v posledním čtvrtletí předcházejícího roku, aby přechodné období nebylo příliš dlouhé.\nVe Venezuele mezitím pokračuje katastrofální hospodářská krize. Podle agentury AP chybí potraviny, léky a základní potřeby a obyvatelé stojí mnohahodinové fronty nebo rabují obchody. Inflace je trojciferná, ale Madura nesvrhly ani loňské mohutné protesty, při kterých zahynuly desítky lidí. Podle průzkumů většina Venezuelanů připisuje vinu za celou situaci Madurovi. Opozice je však ochromená, protože úřady několika jejím hlavním představitelům zakázaly vykonávat politické funkce nebo je vyhnaly do exilu. Některé opoziční strany navíc bojkotovaly nedávné volby starostů, takže tyto funkce získali socialisté.\nTeď opoziční vůdci tvrdí, že do prezidentských voleb postaví jediného společného kandidáta. Je ale otázka, nakolik takový člověk osloví nejchudší vrstvy. I když ani v jejich řadách nepanuje pro Madura nadšení, mnoho lidí se bojí, že by s novým prezidentem mohli přijít o sociální výhody zavedené socialistickou vládou. „Vládnoucí strana sází na to, že má větší šance vyhrát v dubnu než na konci roku, kdy se ekonomika ještě víc zhorší,“ vysvětluje americký odborník na Venezuelu Geoff Ramsey.\nBývalý řidič ruinuje v zemi trh\nBývalý řidič autobusu Maduro, který se stal prezidentem po smrti Huga Cháveze v roce 2013, zruinoval kdysi vzkvétající hospodářství těžící z příjmů z ropy, nastolil v zemi diktaturu a pokřivil volební systém tak, aby nahrával vládě socialistů, dodává agentura Reuters.\nHned po vypsání termínu hlasování zahájil předvolební kampaň na „protitrumpovském základě“. Jeho vláda dlouhodobě tvrdí, že bojuje proti spiknutí venezuelské pravice s Američany, jehož cílem je údajně svržení socialismu ve Venezuele a „ukradení jejího ropného bohatství“.\nOpozice však do voleb nemá koho nasadit. Její nejpopulárnější představitelé buď nesmějí kandidovat, nebo jsou ve vězení či v exilu. Politologové upozorňují, že volby proběhnou podle Madurových podmínek tak, aby měl zajištěné vítězství.\nProtest proti prezidentu Madurovi|foto: flickr.com , Carlos Díaz, CC BY 2.0\nČást opozice se proto opět přiklání k bojkotu hlasování. Ten by ale mohl zkomplikovat záměr postavit jediného společného kandidáta. Zájem už projevili dva, Henry Ramos Allup a Henry Falcón. Ani jeden se však netěší všeobecné podpoře, Ramose Allupa považuje část opozice za příliš tradičního a na Falcóna pohlíží s nedůvěrou, protože kdysi podporoval Cháveze.\nMnoho Venezuelanů má navíc politických stran už dost a touží po nových tvářích. Někteří vyzývají ke kandidatuře dlouhovlasého miliardáře Lorenza Mendozu, ale ten zatím nereagoval, informuje Reuters.\nVenezuelský prezident Maduro se chová jako šílenec


31 Květen, 2020, 17:53:59\n► Život plný utrpení\nZaložil BeeSee, 25 Září, 2012, 17:15:50\n25 Září, 2012, 17:15:50 Naposled upraveno: 25 Září, 2012, 17:19:24 od BeeSee\nŠestý book oblíbené série Živí mrtví neboli The Walking dead se už dostal na tuzemské knižní pulty. Nese název Život plný utrpení a děj v něm graduje jako zatím v žádném předchozím sešitu. Navíc i filmová resp. seriálová adaptace tohoto komiksu přispěla k jeho velké popularitě. Už i u nás můžeme na komerční televizi hltat záběry s vyhřezlými střevy, opadávajícím masem a velmi špatně artikulujícími zombíky. Samozřejmě tohle vše jen standardní omáčka postapokalyptického světa, který stejně všichni realisticky smýšlející jedinci zaručeně čekají. Světa po katastrofě, kde přežívají jen ti nejsilnější, nejotrlejší, nejdůmyslnější a samozřejmě hlavně ti největší zmrdi.\nJiž to bylo (i mnou) zmíněno nesčetněkrát, scénárista Robert Kirkman tuhle sérii rozehrál v hodně velkém stylu. Nejenže svůj svět plný oživlých mrtvol důkladně promyslel, což sice v ,,zombáckém" žánru není nic neobvyklého, ale také se nesoustředí jen na samotný příběh a akční scény s hlodajícími bezmozky. Dokázal si velmi zručně pohrát i s psychologií svých postav a vetknout jim do vínku různé špatné vlastnosti, duševní poruchy, chmury a strach. Ne každý rek jednoduše musí být neposkvrněný jako ono legendární bezkopulační početí. Pokud bojujete ve světě, kde je v podstatě všechno špatně, musíte své špatné stránky jednoduše využít ku svému prospěchu. Protože vždycky se najde někdo, kdo je mnohem zkaženější a zákeřnější než vy, a kdo je tisíckrát větší hajzl a nebojí se to dát najevo.\nPřesně o tomhle je i šestý díl téhle prohnívající řady. Již v minulém díle jste se mohli potkat zatím s největším záporákem celé série, slyšícím na jméno Guvernér. Tenhle chlap to jednoduše nemá v hlavě v pořádku! Je mnohem více zkažený a prohnilý, než ty hromady zombies slintajících za plotem vězení. Tyran či diktátor jsou velmi slabá slova pro vystihnutí charakteru tohohle despoty. A tenhle týpek se dostane do křížku s našimi hrdiny, jmenovitě Rickem, Glennem a Michonne. Právě posledně jmenovaná má na Guvernéra slušnou pifku, protože se k ní nechoval zrovna galantně. Upřímně řečeno se k ní choval jako hovadu čtvrté nápravně výchovné skupiny pro sexuální devianty a jinou pakáž. Navíc za zdmi vězení zůstávají všichni ostatní, které naše trojčlenná pátrací skupina opustila. A životy všech jsou v ohrožení...\nV tomhle díle vás Robert Kirkman nenechá ani na chvíli vydechnout a akce střídá akci. Vše samozřejmě plně podporuje kreslíř Charles Adlard, který svou práci s detaily a nechutnými scénami zvládá na jedničku a je mu k tomu dán dostatečný prostor. Zabývá se nejen detaily obličejů hlavních hrdinů, ale také se soustředí na prohnilé ksichty zahnívajících zombíků. V tomhle se jeho práce na téhle sérii jeví jako nedocenitelná. Tváře s odpadávajícím masem jsou předloženy se zručností etablovaného patologa a trupy živých mrtvých mají také často blízko k tělům zdevastovaným při hromadném leteckém neštěstí či pumovém útoku.\nPokud sledujete českou komiksovou verzi příběhu, zároveň se věnujete i originálu, kde jsou američtí vydavatelé o pár desítek dílů dopředu a ke všemu sjíždíte televizní seriál, tak vám to může krom nádherných snů plných rozkládajícího se masa, způsobit také solidní guláš v hlavě. Zvláště v konfrontaci s filmovým zpracováním, kde se Kirkman, rovněž co by scénárista, rozhodl pozměnit některé dějové linie a tím zvětšit napjetí a nepředpokladatelnost děje. Otázkou tedy jen je, jestli i on si stále zachovává zdravý rozum nebo jestli už mu to taky v hlavě prohnile žbluňká...\nAť je to jak chce, tak tuzemští komiksoví fanoušci, kteří zbožňují postapo a zombáry si rozhodně přijdou na své a je třeba pevně věřit, že živí mrtví budou ještě nějakou dobu mátožně pochodovat po našich luzích a hájích.


Osobní rozvoj » MojeMedicina.cz\nPro studenty »\nO úspěchu, nejen ve studiu ale také v budoucí práci, není třeba jen znalostí a dovedností v oboru, ale také tzv. "měkkých" dovedností. Efektivitě studia, účelnému zacházení s vlastním časem, kvalitní komunikaci a spolupráci mezi různými typy lidí, schopnosti řízení a organizace sebe samého a přesvědčivé prezentace a vyjednávání je věnována samostatná sekce.\nFiltrovat Počet nalezených článků: 11\nKomunikace v kostce\n4. 4. 2016 Komunikace je stará jako lidstvo samo. Proč nám tedy i ve 21. století dělá potíž správně vyslovit myšlenku tak, aby nás druzí pochopili? V dnešním videu se dozvíte, jak funguje převod mezi myšlenkou a řečí a o tom, co s tím můžeme dělat, když nám to zrovna moc nejde. Video:\nJak používat iTunes U\n29. 3. 2016 Možností, jak se sebevzdělávat, je dnes celá řada. Jednou z nich je vyzkoušet aplikaci iTunes U, která nabízí spoustu vzdělávacích materiálů včetně audio a video obsahu. Můžete zde najít video přednášky ze základních i středních škol, ale také z univerzit z Velké Británie či Austrálie. iTunes U je nabízeno zcela zdarma, můžete se tedy vzdělávat a učit téměř neustále. V dnešním podcastu si můžete poslechnout, jak aplikaci iTunes U používat a jak využít všechny možnosti, které nabízí. Video:\n21. 3. 2016 Technologie a medicína k sobě patří již od nepaměti. Trendem poslední doby jsou chytrá zařízení a také takzvané “wearables” - chytré hodinky a náramky. Podívejte se na video, ve kterém se dozvíte, jak se dá pomocí chytrých zařízení sledovat zdravotní stav pacienta a v čem to může do budoucna lékařům velmi pomoci. Video:\n15. 3. 2016 Aplikace Evernote je takový virtuální poznámkový blok, ve kterém můžete vytvářet rychlé poznámky, zapisovat si úkoly, přidávat obrázky a všechno mít neustále u sebe. V dnešním videu se dozvíte, jak aplikaci používat, aby vám přinesla co nejvíce užitku a ušetřila vám tak čas i práci při psaní poznámek. Video:\nJak na slona aneb emoce v komunikaci\n30. 12. 2015 Emoce jsou přirozenou a pravdivou součástí komunikace. Neignorujte emoce a nebojujte s nimi. Jak (nejen v novém roce) na emoce v komunikaci? Podívejte se na naše nové video a dozvíte se jak udržet vlastního slona v klidu, jak nenaštvat slony lidí okolo a jak zastavit slona, který už se rozběhl, zkrátka jak zvládat emoce v komunikaci. Video:\n13. 11. 2015 Duševní odolnost je kvalita, která do jisté míry určuje, jak produktivní jedinec bude, je-li vystaven stresorům, tlaku a výzvám. Studenti, kteří podávají dobrý výkon při cvičeních, nemusí podávat perfektní výkon při testech a zároveň studenti, kteří při cvičeních nejsou extra výkonní, mohou být při testech lepší, než průměr. Duševní odolnost ovlivňuje až 25% našeho výkonu. Jsme-li schopni zvládat tlak a minimalizovat účinky stresorů, pravděpodobně budeme schopni podat i lepší výkon. Poslechněte si, jak se stresory pracovat a jak odolávat tlaku. Video:\nJak na změnu (aby ji chtěl i slon)\n19. 10. 2015 Od přírody nemáme změnu rádi a nechceme se měnit. Pro přírodu je důležité, abychom ušetřili energii, tedy dělali stejné věci pořád dokola s méně vydanou energií. Jenže někdy je změny třeba, rozumově se pro ni rozhodneme, ale realizace je neskutečně těžká. Proč to tak je? Rozhodli jste se něco změnit? Poradíme vám, jak změnu provést, tak aby pro vás byla příjemná nebo alespoň jednodušší. Podívejte se, jak pracovat s emocemi a se změnou. Video:\nUčíme se učit\n1. 9. 2015 Učíme se všichni po celý život. Je na nás, jak k informacím a učení přistupujeme. Poslechněte si řadu doporučení, jak se naučit a zároveň uchovat získané znalosti, zkušenosti a informace a být schopni je aplikovat do budoucna. Tipy, nejen pro první školní den, zahrnují proces učení, používání "háčků", proces plánování a odpočinku, práci s poznámkami a doporučení, jak si látku zapamatovat. Video:\nZvládněte svůj čas pomocí metody GTD (Getting Things Done)\n23. 3. 2015 Nestíháte? Stresují vás nové úkoly, které na vás "padají"? Nebo stíháte, ale chcete být efektivnější? Zkuste metodu Getting Things Done. Video:\niPad - užitečný pomocník\n5. 2. 2015 Chcete svůj iPad proměnit v nástroj, který vám pomůže se studiem, prací či každodenní agendou? Nechte se inspirovat výběrem užitečných aplikací od Petra Máry. Video:\nProdejte znalosti a myšlenky pomocí účinné prezentace\n5. 2. 2015 Pokud si myslíte, že příprava na prezentaci začíná otevřením Powerpointu neměli byste si nechat ujít toto video. Sekundární navigace\nPro studentyPřednáškyOsobní rozvojO projektuZpět na Pro studenty Vyhledávání\nPro studenty Přednášky


Běžný prodej: 858 Kč\nNaše cena: 572 Kč Ověřit dostupnost\nKvětináč 6-ti úhelný -rozměr:ø37x23cm.Technické údaje:výška výrobku: 23cmšířka výrobku: ø37cmhmotnost výrobku: 6kgmateriál: borovicebarva: impregnaceObsah balení:1x Květináč 6-ti úhelný - MALÝ\nJosef Pellant, Zábeštní Lhota:\nKdyž už si něco objednávám, tak chci, abych měl jistotu, že mi k tomu dávají taky zdarma službu, zakoupení přes internet, potencionální možnost vrácení produktu a samozřejmě uvítám co nejrychlejší doručení. Nejednou jsem se spálil a nedůvěřuji preventivně. Zde mě ale nezklamali, byla to skutečně hodně perfektní volba. Je příjemné vědět kde dělají svou práci profesionálně.\nJan Mádl, Hřibojedy:\nTento jsem objevil shodou okolností na internetu. Hodnocení na něj byly veskrze výborné, takže jsem si řekl, že to nemusí být přílišný risk. Přirozeně jsem měl pochyby, to je zřejmě při koupi na internetu přirozené, ale ve chvíli, kdy mi přišel až ke dveřím, přišel jsem na to, že strach byl úplně zbytečné. Funguje bez chyby, fakt mi pomáhá a zpětně jsem velice rád, že jsem si ho nechal zaslat. Bomba!\nEva Hintenausová, Suchá:\nChtěla jsem vyzkoušet zdravější variantu a příjemně mě překvapil i svou lehkostí, určitě u něj zůstanu a chci otestovat i ostatní druhy s příchutěmi. S trochou mléka a zeleninou je to bomba, doporučuji.\nJakub Kičmer, Vrcovice:\nMusím Vám říct, že k jsem byl zpočátku trochu skeptický. Tak perfektní cena, za jakou se prodává, mi byla poněkud překvapivá. Na doporučení švagra, který mi to vychválil a ujistil mě, že s jeho koupí nemůžu nic pokazit, jsem překonal mou vrozenou opatrnost a zkusil si objednat. Když mi přišel domů, hned jsem ho šel zkusit. Dnes musím uznat, že dalece předčil mé očekávání! Určitě doporučuji, protože je to něco, co jsem už léta v domácnosti potřeboval!\nŠtěpán Nemčok, Převýšov:\nTenhle jsem nakupoval poprvé. Upřímně jsem nevěděl, co od toho můžu čekat a byl jsem mile překvapený. Navíc produkt neodpovídá ceně, cena byla nízká, ale výrobek je super! Takže můžu jen doporučit. Když přidám výhody co se týče okamžitosti doručení a zabalení balíčku, tak jsem opravdu zcela spokojen a potěšen, že i slušné Eshopy se u nás v kraji najdou. Doporučuji!\nhodnocení 5/5 od 102 hodnotících\nDominika Z: Pockejte na ocni vysetreni a uvidite jak je to skvele\nDenis H: je to fajné\nNela B: Ideální k osmnáctinám :)\nJana R: Pěkně sedí a jsou stálobarevné\nSára T: Kočka to podrápala a musím pořídit další. Mám štěstí, že to mají skladem a posílají hned.


Podpora studia (knihovny, studovny) | UTB Podpora studia (knihovny, studovny) | UTB\nPodpora studia (knihovny, studovny)\nZařízení pro studenty se specifickými potřebami\nKnihovna UTB ve Zlíně je největší odbornou knihovnou ve Zlínském kraji a sídlí v budově Univerzitního centra (U13). Obsluhuje téměř 12 tisíc uživatelů, z nichž převážnou většinu tvoří studenti a zaměstnanci univerzity, ale také zhruba 700 čtenářů z řad odborné veřejnosti. Knihovna má otevřeno 6 dní v týdnu a v roce 2017 zaznamenala více než 148 tisíc návštěv. Ve fondu se nachází zhruba 130 tisíc knih, na dvě stovky titulů tištěných novin a časopisů, zvukové a audiovizuální dokumenty nebo veškerá produkce elektronických kvalifikačních prací studentů univerzity. Knihovna zpřístupňuje také téměř stovku vědeckých databází, jejichž obsah tvoří tisíce článků z prestižních vědeckých časopisů a e-knihy. Poskytuje řadu školení a konzultací, meziknihovní výpůjčky dokumentů z jiných knihoven z ČR či zahraničí a širokou paletu dalších služeb. Knihovna Univerzity Tomáše Bati ve Zlíně buduje specializovaný fond odborné literatury k zajištění informačních potřeb vzdělávací, vědecké a výzkumné činnosti školy. Veškeré dokumenty, které jsou uložené v knihovně, můžete najít přes katalog knihovny.\nPondělí – čtvrtek 08:00 – 20:00\nKromě univerzitní knihovny mohou studenti využívat i Krajskou knihovnu Františka Bartoše s řadou poboček po celém Zlínsku, která je největší knihovnou ve Zlínském kraji (cca 450 000 dokumentů ve fondu).\nSoučástí knihovny je také univerzitní nakladatelství, které kromě vydávání odborných publikací nabízí prodej a tisk studijních materiálů a také služby spojené s tiskem a vazbou závěrečných (bakalářských, diplomových a dizertačních) prací.\nStudovna je součástí knihovny UTB ve Zlíně a sídlí rovněž v budově Univerzitního centra (U13). Nachází se zde více než 500 studijních míst a uživatelům je k dispozici přes 200 počítačů a dostatek dalších přípojných míst pro notebooky, 6 individuálních studoven (v každém patře jsou dvě), relaxační místnosti či obývák. Při své práci mohou uživatelé používat síťovou tiskárnu, kopírku a skener. UTB provozuje rovněž areálovou studovnu v Uherském Hradišti, v sídle Fakulty logistiky a krizového řízení.\nUniverzitní studovna – otvírací doba\nAreálová studovna v Uherském Hradišti – otvírací doba\nPondělí – čtvrtek 08:30 – 17:00\nPátek 08:30 – 15:00


Architekt Jan Kaplický (\nArchitekt Jan Kaplický (*1937–†2009)Jan Kaplický se do povědomí široké veřejnostidostal díky neobvyklému návrhu nové Národníknihovny v Praze. Zeleným blobem či chobotnicírozdělil český národ na dva tábory. Prvnískupina návrh odsuzuje, druhá v něm vidízajímavé architektonické řešení a zpestřeníLetenské pláně.Kaplický si přál, aby v Česku bylopostaveno jeho dílo, ale namístotoho se setkal s nesouhlasema nelibostí. Jediným odkazemKaplického tvorby v rodné zemitak zůstává dům s ateliérem proF. Dvořáka v Praze z roku 1967.Jan Kaplický se narodil 18. dubna1937 v Praze. Poměrně rychlesi vybral zaměření své budoucíkariéry – architekturu a design.Domácí prostředí mu naprostovyhovovalo, oba rodiče byli umělci,svého talentovaného synapodporovali. Zásadní vliv na nějměl otec Josef, který živil rodinujako malíř, sochař a architekt.Jakmile vzal mladý Jan tužkudo ruky, bylo jasné, že připravíučitele o mnoho energie. Přeučitho z leváka na praváka se jim nikdynepodařilo, naopak přispělok pozoruhodné dovednosti. JanKaplický dokázal v krizových situacíchvzít tužky do levé i pravéruky a současně kreslit. V roce1956 byl přijat na Vysokou školuuměleckoprůmyslovou v Praze.V období studia svůj talent rozvíjelnapříklad i módními návrhy prostudentky. U plavek se přednostněinspiroval minimalizmem.Cesta doVelké BritániePo ruské okupaci odcestovalJan Kaplický do Londýna. Střets volností, ale zároveň nedůvěřivostík přistěhovalcům znamenalobdobí mizerných platů. Měl všakštěstí, kam přišel, tam běhemkrátké chvíle přesvědčil kolegyi zaměstnavatele o svém nespornémtalentu. Za zmínku stojípůsobení v ateliéru Renza Pianaa Richarda Rodgerse, s nimiž sepodílel na realizaci Centre GeorgesPompidou v Paříži.Ale touha po vlastním ateliérubyla mnohem větší. Spolu s DavidemNixonem založili v roce 1979společnost Future Systems.V následujícím desetiletém obdobípublikovali množství prací,absolvovali přednášky a výstavy,čímž se Future Systems a zvláštěKaplický dostali do povědomíodborné veřejnosti. Zájemo spolupráci dokonce projevilamerický Národní úřad pro letectvía kosmonautiku (NASA), pro kterýKaplický navrhl například skládacístůl přizpůsobený k používánív prostředí s nulovou gravitací.Přestože Kaplický vyrůstal v prostředíčeského funkcionalizmu,tak tímto slohem se nikdy ovlivnitnenechal. Nápady hledal najiných místech.„Příroda i lidské tělo nezná rovnékřivky,“ neuznával Kaplický strohosta účelovost funkcionalizmu.Kaplický ve svých plánech prosazovaltzv. organickou architekturubez rovných čar a přímek.V roce 1989 vstoupila do týmuFuture Systems Amanda Levete,která se stala jeho pracovní i nanějaký čas životní partnerkou.S jejím příchodem nastalo obdobíúspěchů. Přibývaly zakázkya ocenění. Vítězství v architektonickýchsoutěžích sice nadáleunikalo, ale druhá a třetí místabohatě stačila k upoutání pozornosti.Dům Hauer & King v Londýně,postavený v roce 1992,patří mezi první významné realizaceFuture Systems. Schodištěčtyřpodlažního domu je umístěnokolmo ke vstupu, čímž se získalyprostory navíc pro obytné místnosti.Dojem křehké stavby budífasáda, která je tvořená z luxferů.V řadové zástavbě si domu Hauer& King nelze nevšimnout.Vrchol kariéryZásadní zvrat v působení JanaKaplického a Future Systemsse stal v roce 1994. Zatímcomnozí jeho vrstevníci přemýšlelio klidném prožití stáří, Kaplickýnaopak zvyšoval své nasazení.Plovoucím mostem pro pěšív Docklands dokázal, že profesionalitua zároveň pokrokovoststaveb si dokáže udržet i v pokročilémvěku. Most je vybudovánz prefabrikovaných dílů. Tentosystém Kaplický koneckoncůvždy upřednostňoval. Lehká ocelovákonstrukce stojí na čtyřechpěnou vyplněných pontonech,ukotvených v betonových pilotách.Noční pohled na most jedíky jeho zelené barvě impozantní,pravidelně rozmístěné osvětlenívytváří nepřehlédnutelnouspojku mezi oběma břehy.Nejlepší i nejhoršístavbaZa další významnou zakázku JanaKaplického lze považovat tiskovécentrum NatWest Media Centrena kriketovém stadionu Lord’sCricket Club v Londýně. Centrumpřipomíná periskop s výhledemna celé hřiště. Jedná se o poloskořepinovoubudovu vyrobenouz hliníkových prefabrikátů, každýz dílů o rozměrech 3x20 m váží až6 t. Hladkého a lesklého povrchu sedosáhlo precizním přebroušeníma bílým nátěrem. „Oko nad stadionem“stojí na dvou betonovýchpilířích, které ve svém nitru ukrývajíschodiště a výtahy. Přední částbudovy je zasklená laminátovýmtvrzeným sklem v úhlu 25°. Kaplickýse tím chtěl vyvarovat případnýmodleskům slunce a zabezpečitojedinělý výhled na hrací plochu. Po8stavebnictví 02/09\nskončení životnosti tiskového centraby mělo být možné až 80 % budovyrecyklovat. Za realizaci, která ovšemdvojnásobně překročila původnírozpočet, získal Kaplický prestižníbritskou cenu za architekturu StirlingPrize. Za zmínku určitě stojí i květinářstvíWild at Heart v Londýně.Jednoduchý bílý interiér s květinamizapuštěnými do různě tvarovanýchpolic se ale nedochoval.Snad nejznámější Kaplickéhostavba stojí v Birminghamu, jednáse o obchodní centrum Selfridgesz roku 2003. To, podobně jakov České republice Národní knihovna,přitáhlo obrovskou pozornostlaiků i odborníků a v Británii sepostaralo o solidní mediální rozruch(naštěstí pro Kaplického tentokrátaž po realizaci stavby). Po boku novogotickéhokostela utváří Selfridgeskontrast mezi minulostía budoucností stavebnictví a architektury.Oblým tvarům dominujepozoruhodná fasáda z anionizovanéhohliníku, jednotlivé tabule jsoupřipevněny na betonovém skeletua odrážejí světlo. Každé patro neserukopis jiného architekta z FutureSystems, proto je interiér jedinečnýstejně jako exteriér. Novodobouarchitekturu, buď lidé milují, neboji nenávidí. V lepším případě si nanezvyklé dílo uprostřed historickézástavby zvyknou. V Birminghamusi však lidé na šest let staréobchodní centrum zatím nezvykli,Kaplického Selfridges bylo zvolenonejhorší stavbou Velké Británie.V současné době probíhá realizacemuzea Enza Ferrariho v Modeně.O první spolupráci s nejslavnějšíautomobilkou světa se ale nejedná.V roce 2001 navrhl ateliér FutureSystems veletržní stánek proautomobilové značky Ferrari a Maserati.Základním požadavkem bylapřevaha červené barvy za předpokladu,že stejně zbarvené vozyvyniknou. O tři roky později se JanKaplický zúčastnil architektonickésoutěže na zmiňované muzeum.Projekt zvítězil a v letošním roceby měla být stavba dokončena.Muzeum Enza Ferrariho, kde najdoutrvalé útočiště vozy a závodnímonoposty Maserati, nepobuřuje,naopak se velmi těžko hledá negativnínázor na v zemi zapuštěnýodkaz italské značky. Vstup do muzeaje orientován přes zakřivenou▲ Tiskové centrum NatWest Media Centre znamenalo prestižní britskou cenu za architekturu Stirling Prize▲ Nepochopený kontrast: obchodní dům Selfridges vedle novogotického kostela znamenal „ocenění“ za nejhoršístavbu Velké Británieskleněnou stěnu, která návštěvníkůmnabídne dokonalý přehledo rozmístění exponátů. Přístupdenního světla zajišťují střešnísvětlíky. Kaplický ve fázi projektovánínevycházel z přírody, nýbržpřímo z vozu Maserati. Celkový pohledna vizualizaci silně připomíná„vytrhnutou“ kapotu z padesát letstarého monopostu formule 1.Enzo Ferrari Muzeum je tak poslednístavbou, jejíhož realizováníse Jan Kaplický dožil. Ačkoliv bylpředevším architektem a designérem,který navrhoval „do šuplíku“,každou uskutečněnou stavbouvzbudil ohlas. Možná se Česká republikanakonec dočká a v ČeskýchBudějovicích vyroste koncertnía kongresové centrum AntonínaDvořáka. Možná se dostane i naNárodní knihovnu, ale zde stojínávrh nejen proti silným soupeřůmz oboru, ale hlavně proti silnýmsoupeřům z politického prostředí,pro něž by paradoxně křivé, pokroucenéa zahnuté linky měly býtrelativně přirozenými tvary. ■Aleš Sirný, 4stav.czstavebnictví 02/09 9\nPage 7: BAU 2009: krize se výrazněneproje


dominik577, 25.06.2011 19:37 , Leguán zelený, 16 odpovědí (12016 zobrazení)\nTlamu bych videl na nedostatek Uvb,D3 takze poridit poradny zdroj Uvb. Ocasek asi nejaka spalenina r…\nSvítit 5 hodin denně nemusí rozhodně znamenat dost. Kromě toho neuvádíte, JAKÝM zdrojem leguánovi sv…\nRepti Glo 5 UVB.Bylo tam psane,ze staci 4hod denně hm tak s tim když na něj budeš 4h svítit baterko…\nRepti Glo vyhoďte, textům na obalu nevěřte - já vím, je to smutné - a prokonzultujte vhodné osvětlen…\nachjo tak to dopada kdyz nekdo koupi zvire ze zverimexu a predtim si nezjisti nic o chovu.. Ty ceske…\nDobře Uvb pořídím nove!;-) A dorostou leguánovi někdy ty trny?\nTak strihat se da ale nesmis strihat dal nez ma "zilku" v drapu ( to cerny ). Ale kdyz ma v terarku…


Giant liga vzdala hold Šimůnkovi - Plzeňský deník\nGiant liga vzdala hold Šimůnkovi\nPlzeň – Třináctý díl Giant ligy vyhrál František Raboň z výběru České republiky.\nIlustrační fotoFoto: Tereza Kotalová\nGrand Prix TomasHruby.com byl přehlídkou cyklistických osobností mezi diváky. Do sportovního areálu dorazil i čtyřnásobný mistr republiky Václav Toman, Lubor Tesař a další bývalí jezdci, kteří pak společně s ostatními cyklisty a fanoušky uctili minutou ticha památku zesnulého Radomíra Šimůnka.\nNa startu pak diváci vedle hlavní hvězdy závodu Františka Raboně (výběr ČR) mohli vidět zlatého paralympionika a mistra světa Jiřího Ježka (Tusnad Cycling Team), Michala Starka a Jiřího Boušku připravující se na mistrovství světa handicapovaných cyklistů. Nechyběli ani dráhaři pražské Dukly – mistr Evropy Jan Dostál a vynikající Milan Kadlec. Skvěle se uvedl po nemoci i cyklokrosař Martin Zlámalík (Sunweb Revor).\nOd prvních metrů se rozjelo vysoké tempo. Závod se jel opačným směrem a jezdci bodovali v každém kole a připisovali si na účet dva a jeden bod. Nikomu se nepodařilo odskočit na delší dobu a ukořistit důležité body. Jediný, kdo dokázal z rozjetého vlaku ještě poodskočit a zrychlit tempo, byl František Raboň (výběr ČR).\nDo soutěže aktivity Kiss Proton prestige se opřeli a o prvenství přetahovali Martin Zlámalík (Sunweb Revor) a Michal Plesník (Alpine Pro Author). O jediný bod pak zvítězil Plesník a za 14 dní se předvede v puntíkovaném dresu nejaktivnějšího jezdce. O vítězství v ženách rozhodl opět závěrečný spurt, kde měla nejvíce sil Lucie Záleská (ASC Dukla Praha). V juniorech si dospurtoval pro vítězství Martin Rabovský (TJ ZČE Cyklistika Plzeň).\nVýsledky 11. srpna 2010:\nGP TomasHruby.com. Čas vítěze: 1:09.52h 55 km 1. František Raboň (výběr ČR) 25b, 2. Jan Dostál (ASC Dukla Praha) 17b, 3. Ondřej Zelinka (TeamFanflash) 15b.\nPowerBar Cup Juniorů: 1. Martin Rabovský, 2. Denis Rugovac (oba TJ ZČE Cyklistika Plzeň), 3. Petr Šulc (Team CUBE – Wattsenglish).\nSýkora sportswear Cup (ženy): 1. Lucie Záleská (ASC Dukla Praha), 2. Tereza Trefná (Alltraining.cz) 3. Katarina Hranaiová (AC Sparta Praha).\nKISS Proton prestige (soutěž aktivity): 1. místo Michal Plesník (Alpine Pro Author) 5b.\nNaCesty.cz CUP (soutěž jezdců nad 40 let): 1. Jiří Tobrman (Duratec – Jambor uhelné sklady).


Úklid a mytí nádobí - Praha 9 - Bazoš.cz\nHlavní stránka > Práce > Pohostinství a ubytování > Inzerát č. 111966408\nSportovní hospoda v Horních Počernicích přijme paní na úklid a mytí nádobí.Pracovní doba po-pá od 8,00 do 14,00..Nástup možný ihned.100kč/hod..\nPráce v jídelně Kolín - [9.11. 2019]\nDo nově otevírané, zrekonstruované jídelny v Kolíně přijmeme spolehlivé pracovníky na pozici kuchaře a pomocnou sílu na úklid a nádobí. Nástup možný ihned! V případě zájmu o práci pošlete svůj životopis spolu s telefonním kontaktem na mail: jidelnakolin@email.cz\n542 27 1519 x


Řidička se lekla auta a narazila do stromu | ČtiDoma.cz\nčtidoma.cz > Zpravodajství > Řidička se lekla auta a narazila do stromu\nŘidička se lekla auta a narazila do stromu\nV Zelenči nabourala mladá žena do stromu. Podle její výpovědi se lekla projíždějícího auta. Policie však vyšetřuje i možnost, že si spletla plyn s brzdou.\nŘidička se lekla projíždějícího auta\nOpravdu kuriózní nehoda se stala v obci Zeleneč na Praze-východ. Policie zde vyšetřuje nehodu, kdy mladá řidička v ulici Československé armády narazila se svým Seatem do stromu. Řidička vyjížděla z boční ulice a údajně se prý lekla projíždějícího vozidla a nabourala do stromu.\nPro zraněnou cyklistku letěl vrtulník. Utrpěla vážná zranění.\nJen s velkým štěstím se nikomu nic nestalo. Dvacet minut před nehodou byl v její těsné blízkosti zmrzlinový stánek, v té době mohly být následky mnohem vážnější.\nNa místě nehody se spekulovalo o tom, že si mladá řidička spletla plyn s brzdou. Policie však celý průběh ještě vyšetřuje. Na místě zasahovala policie, záchranná služba i hasiči.\nDva mrtví po srážce automobilu se stromem. Další zbytečná smrt.\nMladé slečně Nikole se zpět do výchovného ústavu evidentně nechce. Už jedenáckrát utekla, ale pokaždé se zase našla. Teď je na...