Sun propustí dva tisíce zaměstnanců, projevuje se akvizice MySQL?

Podle informací ze čtvrtletní zprávy to vypadá, že problém vznikl už před Q2 (pravděpodobně v průběhu Q1 protože výsledky jsou zpětně) a první signál pochází ze služeb (hrubá marže ze 49,2% v Q1 na 48,7% v Q2 a propadem na 45,2% v Q3). Zajímavý je téměř souhlasný propad v Q3 jak produktů tak služeb. To by mohlo být způsobeno rozeznáním výnosů (meziročně Q2 24% / Q3 6%) před koncem fiskálu. Z geografického pohledu je vidět propad opravdu jen v US (což je vidět už v Q2!). Ostatní regiony pomalu rostou. Zajímavé je, že v Q3 má SUN čistou ztrátu, která není vysoká (mimochodem, tím silné tažení SUN v pěti ziskových kvartálech končí), ale formou odpisů, daní a dopadu akvizicí (MySQL, innotek) je celkově v zisku. Podle mého názoru by propouštění o 2000 - 2500 zaměstnanců mělo zlepšit OPEX a tím zlepšit provozní zisk v Q4 a dál.

už Sunu patří ne?

.. patří co já vím - http://www.blue-point.cz/os2/cs/sun-koupil-firmu-innotek-virtualbox

Chvalme Postgres!

nevim cemu by to prospelo, OpenSolaris sice neni pod GPL, ale necim podobny a konkurence na poli OS neni vubec na skodu. Java ma byt pod GPL taky cela a na urcite veci je to perfektni jazyk.

no prave solaris a java jsou ok, ale MySQL by mohli zrusit a zakopat

Co ti tak strasne vadi na mysql?

Třeba to, že to není opravdová relační databáze avšak snažá se ten dojem budit?

Třeba to, že už jednu generaci začínajících programátorů zničilo a zdeformovalo jejich pohled na SQL?

to s tym zdeformovanim pohladu na SQL, to je velmi trefne...

vela ludi co si o sebe mysli ze 'ovlada SQL', dokaze napisat tak akurat zopar joinov(aj to za pomoci nejakeho query builderu) a tvrdia ze ovladaju SQL..

mal som na pohovore zopar ludi ktori mali v CV ' SQL - 2 roky - pokrocily/expert'..

zacal som sa ich pytat na nejake tie transakcie, relacie, zopar zlozitejsich subselectov, kurzory, nejake to pokrocile indexovanie a zrazu z 'pokrocily/expert' bol clovek co napisal zopar webov na MySQL a nemal tusenie o com hovorim

Tebe by mohli zrušit a zakopat. Když nechceš, tak to nepoužívej.

Naprosto souhlas, sileny bastl, ktery nema nic s relacni DB spolecneho. Sun se ma drzet rozvoje Javy a ty penize dat do rozsireni mnoha funkci, co jsou treba a ne tohohle pazmeku.

Ono MySQL svůj smysl v některých případech má. Má např. velmi nízkou režii, takže se hodí na titěrné selecty atp. Jen by podle mě nemělo být nazýváno SQL a mělo by poctivě informovat svoje uživatele o tom, jak se věci mají. Já se bohužel setkávám s programátory, kteří o sobě tvrdí, že umějí SQL - přičemž jsou na úrovni MySQL. Většinou mají nenapravitelně zkažený styl, evt. to stojí hodně úsilí je přimět se SQL naučit.

Pořád nechápu, co má společného neschopnost programátorů s kvalitou databáze. Na Wordpress.com MySQL v dubnu servírovala 655 milionu stránek, uložila přes 3m postů a 5m komentářů pro 155 milionu návštevníků. Na nerelační bastl postačují výkon, ne?

No prostě ne. Ten kdo děla v mySQL musí být absolutní nula už z principu věci. To je jasný

Snaha kočkovat se se smečkou zmutovaných psů je nejlepší způsob jak si pořídit značně ošklivou mrtvolu.

>> Pořád nechápu, co má společného neschopnost programátorů s kvalitou databáze.

To, že v klasických databázích se přenáší většina operací na databázový stroj. Využívají se mnohonásobné joiny tabulek a funkcí - a bez ztráty výkonu, resp. se ziskem výkonu. MySQL naopak ve složitějších operacích výkon ztrácí - a tak jsou programátoři nuceni rozdělovat výkon do menších selectů, které pak spojují na aplikační úrovni. Vedlejšími efekty jsou to, že na MySQL programátoři rádi používají různé pomocné tabulky pro urychlení atp. A to je právě to, v čem MySQL kazí lidem styl. U opravdové databáze nic z toho není potřeba.

Ono se to v krátkosti špatně vysvětluje. Každopádně toto Vám potvrdí kdokoliv, kdo umí využít funkce opravdových SQL strojů.

Hlavne mysql v nekterych vecech s defaultnim nastavenim odporuje standardum. Uplne "genialni" je, ze v tabulce jde definovat sloupec cislneho typu a not null, ale pri pokusu vlozit tam retezec to nehodi chybu (akorat nejaky warning) a jeste to tam ten radek ulozi s null. Takovyhle shit se proste neda nazyvat databazi. O tom jak tam funguje groupovani ani nemluvim

Vas prispevek mi prijde krapatko kratkozraky a strnuly pohled. Svet neni tak cernobily.... Vyuzivani vicenasobnych joinu bez ztraty vykonu - co je to za nesmysl? Nic neni zadarmo, joiny urcite zatezuji databazi... Prenaseni operaci na databazovy stroj - to taky radeji ne - databaze se dost blbe skaluji, takze asi brzo narazite na problemy s vykonem. Mit 10 webserveru neni problem, s databazovymi stroji je to slozitejsi...

Co rikate na tohle (trochu extremisticky pristu k DB, ale tihle lidi asi nejsou uplni pitomci) - http://jablok.wordpress.com/2008/04/28/ebay-java-skalovatelnost/

(Ne, MySQL opravdu nepouzivam, trapis spis Oracle, Informix a podobne potvory ;)

>> Svet neni tak cernobily.... Vyuzivani vicenasobnych joinu bez ztraty vykonu - co je to za nesmysl?

Trochu jsem to zjednodušil pro pohled těch, kteří právě znají MySQL. Mnohonásobné joiny získávají na výkonu oproti odděleným selectům. Neměly by nijak výrazně ztrácet výkon. U MySQL několikanásobný join znamená katastrofickou efektivito.

>> Prenaseni operaci na databazovy stroj - to taky radeji ne - databaze se dost blbe skaluji

Opět, myšleno v intencích toho, s čím se většina lidí zde setká. Business logiku je často nejlepší řešit opravdu na databázovém stroji.

Jinak celkově myslím, že černobíle tyhle věci nevidím. Jak jsem psal, není lehké v krátkosti vysvětlit to, co MySQL chybí. Pokud to dokážete nějak rozumně naformulovat, budu jen rád :)

Hezký večer.

Asi bysme se shodli, ze MySQL neni nejlepsi databaze kterou muzete sehnat. Ale to neni ani Oracle, MSSQL - kazda ma trochu jine vlastnosti a spravne byste mel zvazit co potrebujete podle toho zvolit DB.

Kdyz jsem MySQL zkousel - uz je to dloha doba, asi 5 let - tak MySQL myslim neumela ani referencni integritu, to bylo opravdu usmevne, ale to uz se myslim naucila. Dalsi zajimava vlasnost je, ze uvnitr pouziva ruzne implementace DB stroje (rikaji tomu myslim InnoDB apod), kazda umi trochu neco jineho, ale zadne neumi vsecho poradne :)

V jinem prispevku k tomuhle tematu jste psal ze MySQL neni poradna relacni DB? Co tim vlasne myslite? Ze neumi zaklady jako ACID? - to podle me zvlada, a to staci na to aby se dala povazovat za solidni relacni databazi. Co povazujete za vlastnosti ktere by mela mit opravdova relacni DB? Nejake ladeni vykonu, pocne nastroje na zalohovani, replikaci apod? Nebo propracovane moznosti programovani procedur? Treba procedury podle me s relacni DB primo nesouvisi, je to dalsi bonus, ktery nam umoznuje s DB pracovat...

Osobne sem taky potkal par MySQL+PHP bastliru-programatoru, ale tvrdit ze MySQL, PHP je smejd, protoze kazi lidem styl, to je podle me zbytecne. Je to zalezitosti lidi, ze nemaji dostatecny zajem dohlednout dal nez za bastleni webiku v PHP+MySQL. Kdo chce, tak si styl nezkazi. Psal jse ze mate nejake programatory - takze bud si musite zaplatit ty, kteri nemaji zkazeny styl, nebo si proste levnejsi programatory musite vyskolit :)

Podle vasich prispevku mam dojem, ze asi programujete client/server aplikace s logikou v ulozenych procedurach. Tam asi opravdu potrebujete "velkou" databazi jako Oracle, MSSQL, Informix,... Na takovou architekturu je MySQL asi nepouzitelne.

Ale logika v DB neni vzdycky to nejlepsi - skalovatelnost, prenositenost, udrzovani kodu,... Nektere arhitektury se tomu snazi vyhybat co to jde - logiku prenasi do jine vrstvy (treba aplikacni server) - v tomhle pripade uz by se o MySQL uvazovat dalo...

Takze MySQL urcite neni to nejlepsi co existuje, ale urcite ma svoje misto, kde udela nejlepsi sluzbu. A my bysme se meli umet spravne rozhodnout jakou DB pouzit :)

>> Co povazujete za vlastnosti ktere by mela mit opravdova relacni DB? Nejake ladeni vykonu, pocne nastroje na zalohovani, replikaci apod? Nebo propracovane moznosti programovani procedur? Treba procedury podle me s relacni DB primo nesouvisi, je to dalsi bonus, ktery nam umoznuje s DB pracovat...

Všechno toto. Prostě celkově MySQL svojí stavbou nutí přenášet hodně práce do aplikace. Absence rozumně fungujících triggerů, kvalitní oddělení a zvládání transakcí, prostě vůbec od všeho trochu v MySQL chybí. Vím, učí se to. Ale zase na druhou stranu, je co celé takové slátané, nic nefunguje úplně dobře a už vůbec ne rychle.

Zkuste si na nějaké větší databázi udělat dvacetinásobný join - a pak to samé zkuste udělat oddělenými menšími selecty a slátat to v aplikaci. Překvapivě MySQL dá nižší výkon.

>> Osobne sem taky potkal par MySQL+PHP bastliru-programatoru, ale tvrdit ze MySQL, PHP je smejd, protoze kazi lidem styl, to je podle me zbytecne. Je to zalezitosti lidi, ze nemaji dostatecny zajem dohlednout dal nez za bastleni webiku v PHP+MySQL. Kdo chce, tak si styl nezkazi.

Souhlasím i nesouhlasím. Knihkupectví jsou zaplaveny učebnicemy (My)SQL. Potkávám mladé programátory, kteří ani nevědí, že opravdové vlastnosti SQL sahají někam daleko hlouběji. Právě to je negativní jev, který popisuju. Když už programátor zjistí, co všechno jiné SQL stroje nabízejí, máte pravdu, že tam pak už motivaci najít může a nemusí.

>> Podle vasich prispevku mam dojem, ze asi programujete client/server aplikace s logikou v ulozenych procedurach.

Já už především sám nic neprogramuju, už musím plnit jinou roli v potravinovém řetězci. V prockách se pochopitelně nevyplatí programovat všechno. Některé projekty jsou příliš malé na to, aby se to vyplatilo. Jiné jsou zase příliš velké a dynamické na to, aby procedura nebyla omezujícím mezičlánkem. Dobré však je mít možnost. I u malých projektů se někdy vyplatí udělat zásad triggerovanou procedurou než hledat v kódu apliace místa, která je potřeba změnit - to jen jeden příklad.

>> Takze MySQL urcite neni to nejlepsi co existuje, ale urcite ma svoje misto, kde udela nejlepsi sluzbu.

Ano, to jsem psal také, pod to se též podepisuji. Za velkou přednost MySQL vyzdvihuji nízkou režii při otevírání spojení.

Keď programujete aplikácie postavené na aplikačných (resp. webových) serveroch, tak vám funkcie. ktoré sú v Oracli, MSSQL sú úplne NA NIČ.

.

Triggre, uložené procedury atď, si môžete programovať priamo v jazyku, ktorý používate na strane servera. Nemáte potom logiku aplikácie na dvoch miestach (aplikácia, SQL) ale iba na jednom.

.

Ak navyše robíte v nejakom vyššom jazyku a používate nejaké objektovo-relačné knižnice, tak ani žiadne uložené procedúry nevyužijete a tiež ani nevyužijete nejaké komplikované dotazy cez joiny (a tie v praxi pri veľkom počte údajov nemôžete používať ani v Oracli).

.

Takže pri používaní aplikačných serverov má MySQL výrazne viac výhod ako nevýhod. Ja osobne považujem za jedinú nevýhodu MySQL nemožnosť online zálohovania údajov (resp. komplikovaný spôsob).

>>Ak navyše robíte v nejakom vyššom jazyku a používate nejaké objektovo-relačné knižnice, tak ani žiadne uložené procedúry nevyužijete a tiež ani nevyužijete nejaké komplikované dotazy cez joiny (a tie v praxi pri veľkom počte údajov nemôžete používať ani v Oracli).

Ano, to je pravda. Je to sice škoda, ale velké systémy to opravdu tak mají.

>> Takže pri používaní aplikačných serverov má MySQL výrazne viac výhod ako nevýhod.

To je opravdu věc názoru. Dost často aplikační servery mají ty nejdůležitější (tj. nejčastěji používané nebo naopak nejkomplikovanější) dotazy zpracované právě mírně mimo Vámi zmiňované principy. Také často se v takových případech používají views, které za sebou mají tu složitou logiku.

Taktéž někdy aplikační server nepamatuje na některé situace a opravdu je někdy nutné triggerovat na databázi i v těchto případech.

Takže za sebe říkám, že MySQL je pro mě moc omezující. Na druhou stranu ale plně uznávám to, že dává vyšší výkon těm, kteří se nechtějí věnovat optimalizaci databázové práce a těm, kteří používají knihovny, které raději udělají 20 oddělených selectů, než jeden velký.

Asi jsi MySQL dlouhou dobu neviděl. Tohle možná platilo před 5 lety, od té doby MySQL ušel velký kus cesty.

Ale viděl. Jak říkám, ptejte se těch, kteří nějaké opravdové SQL ovládají a uvidíte, co Vám řeknou za odpověď. Svoje programátory jsem musel přinutit, aby z MySQL přešli na PostgreSQL a MSSQL. Všichni argumentovali tak, jako Vy právě - tj. že MySQL je už jiné. Nakonec mi všichni dali za pravdu a ani jeden už se k MySQL vrátit nechce.

Já sám ho používám jen na provoz phpBB2, které je tak prasácky napsané, že jedině na MySQL má jakýs takýs výkon.

MySQL tábor je nesmírně početný a MySQL odvádí ve výsledku hromadu práce pro svět. Přesto to není dobrá volba.

Ja som ich prinútil aby prešli z Oracle na MySQL.

v oraclu dělám tak 50 procent meo pracovního času, takže nejsem žaden DB expert, ale ORACLE->MySQL byl přechod buď kvůli nákladům, nebo kvůli požadavku zákazníka, nebo lidská hloupost. Kažopádně proti gustu žáden dišputát, ale je to přechod od asi jako od špičkového BMW na hadráka.

Jak s tím souvisí Java?