Komentáře
ke článku: Diskuse::Která platforma je nejhorší?
(ze dne 04. 11. 2009, autor článku: Redakce dbSvet)

Komentář ze dne: 04.11.2009 21:43:03     Reagovat Autor: Mail: @ Titulek: Komentář: Informix

Komentář ze dne: 04.11.2009 22:00:24     Reagovat Autor: Mi.Chal Mail: spamy.nectu@atlas.cz Titulek: Co treba mysql? Komentář: Sice nevim, co je nejhorsi, ale na prednich mistech by se mohlo vyjimat mysql s defaultnim nastavenim. Zajimave, ze to ani minule nikdo nenominoval :-).

Komentář ze dne: 04.11.2009 22:04:05     Reagovat Autor: Mail: @ Titulek: Re: Co treba mysql? Komentář: S mysql souhlasím, přidal bych ještě SQL server od Microsoftu, větší prasečinu jsem snad ještě neviděl.

Komentář ze dne: 04.11.2009 22:13:07     Reagovat Autor: Tomáš Mail: @ Titulek: Re: Re: Co treba mysql? Komentář: Ten paskvil od Microsoftu je snad ještě horší, než MySQL, ne?

Komentář ze dne: 04.11.2009 23:15:50     Reagovat Autor: Mail: @ Titulek: Re: Re: Co treba mysql? Komentář: MSSQL jsem celkem pouzival a zas tak strasny mi neprisel. Neco malo jsem delal i na Oracle, ktery vetsinou vsichni vychvalujou, ale nektere featury mi prijdou dost zvlastni. A ty standardni nastroje k tomu (treba ten Sql Developer v jave) mi prijdou kvalitou uplne priserny, to co bylo u MSSQL7 (starsi jsem nevidel) mi prislo pouzitelnejsi.

Komentář ze dne: 04.11.2009 23:21:52     Reagovat Autor: Mail: @ Titulek: Re: Re: Re: Co treba mysql? Komentář: co přesně ti připadalo zvláštní na Oracle? Promiň nástroje, ty Ora fakt moc neumí, ale databáze mají perfekt. Microsoft naproti tomu má své databáze plné naprosto nelogických chyb...

Komentář ze dne: 04.11.2009 22:39:48     Reagovat Autor: xdrm Mail: xdrm@seznam.cz Titulek: MS SQL Komentář: jo databaze od MS je nehorsi a jeste se za to musi platit

Komentář ze dne: 04.11.2009 22:43:57     Reagovat Autor: Mail: @ Titulek: Re: MS SQL Komentář: co všichni proti microsoftu maji? Sice je to hrozna sračka, ale nejhorší určitě není

Komentář ze dne: 04.11.2009 23:34:18     Reagovat Autor: Neřeknu Mail: @ Titulek: MS SQL Komentář: MS SQL - proč? proboha, vždyť to nedodržuje skoro žádnou normu, má to chyby jak hrom, bezpečnost taky nic moc, zkoušeli jste to někdy opravdu v enterprise segmentu? můj favorit je tedy jasný. a nejlepší bylo, jak mne jednou nějaký idiotek z microsoftu přesvědčoval, že jejich sql je prostě skvělý, vůbec nevěděl, o čem mluví, na žádný argument nebyl schopnej reagovat. někde se tu o něm snad už i psalo, to jméno si ale přesně nepamatuju.

Komentář ze dne: 05.11.2009 08:37:41     Reagovat Autor: Jonáš Mail: jonasxe@seznam.cz Titulek: Re: MS SQL Komentář: Plně se připojuji k tomuto názoru, Oracle jo, Informix jo, DB2 jo, dokonce i Sybase jo, ale SQL od MS opravdu ne.

Komentář ze dne: 05.11.2009 10:07:11     Reagovat Autor: Michal Mail: @ Titulek: Rozdělil bych to Komentář: Rozdělil bych to asi podle kategorií, možná alespoň komerční / nekomerční. V největších komerčních je nejhorší bezesporu MS SQL Server, na největší konkurenci stále strašně moc ztrácí. V nejznámnějších nekomerčních je určitě nejhorší MySQL následováno Firebirdem. Vím, že oba příklady vyvolají negativní reakce, ale MS SQL Server je oproti jiným produktům stejné kategorie děs a hrůza. MySQL je šílenost sama o sobě a Firebird nedosahuje například kvalit PostgreSQL a má docela hodně chyb.

Komentář ze dne: 05.11.2009 10:26:05     Reagovat Autor: Mail: @ Titulek: Re: Rozdělil bych to Komentář: tak pod to se podepisuju

Komentář ze dne: 05.11.2009 10:41:14     Reagovat Autor: Mail: @ Titulek: Re: Re: Rozdělil bych to Komentář: +1

Komentář ze dne: 05.11.2009 16:14:10     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Rozdělil bych to Komentář: Nebudu polemizovat se zbytkem Vašeho příspěvku a podržím se jen Firebirdu. Jednak by mě zajímalo co to znamená že má Firebird "docela hodně chyb". Jakožto osobu zodpovědnou za QA v projektu mě to velice zajímá. Firebird rozhodně nějaké chyby má (jako každý SW), o tom žádná, ale zajímalo by mě jaké chyby z něj dělají *nejhorší* databázový produkt na trhu. Za druhé by mě zajímalo jak jste dospěl k závěru, že nedosahuje kvalit PostgreSQL a jakým způsobem vůbec kvalitu posuzujete (celkový počet fíčur, rychlost, náročnost na zdroje, dostupné platformy, spolehlivost, nebo jak vlastně)? PostgreSQL má řadu vlastností které Firebird nemá, nebo nejsou tak dobře zpracované, nicméně to platí i obráceně (např. o embedded verzi mohou uživatelé PostgreSQL jen snít, a co snadnosti instalace, administrace a provozu má PG taky co dohánět, a to je jen pár příkladů). Nicméně seznam vlastností není kritériem kvality. Mimochodem, i kdyby byl PostgreSQL nakrásno "kvalitnější" než Firebird (což je diskutabilní), nečiní to Firebird apriori nekvalitním produktem, a tudíž kandidátem na nejhorší produkt (což je téma této diskuze).

Komentář ze dne: 05.11.2009 22:08:45     Reagovat Autor: Karel Mail: kaja nereknu Titulek: Re: Re: Rozdělil bych to Komentář: má FB možnost oddělit data od indexů do různých souborů? má FB možnost pokročilých hintů? má FB možnost rozkládání zátěže? .... ??

Komentář ze dne: 06.11.2009 10:10:41     Reagovat Autor: Tomk70 Mail: @ Titulek: Re: Re: Re: Rozdělil bych to Komentář: Snad záleží taky na tom k čemu chci kterou databázi používat. Pokud budu dělat třebas učetní nebo mzdovou agendu krabicový SW tak šáhnu mnohem raději po FB než třebas Postgree SQL právě proto že není třeba nic instalovat/nastavovat. V takových případech mě nějaké rozkládání zátěžě nemusí zajímat. Každý DB produkt je určený pro konkrétni použití a nelze odsoudit jeden proto že nemá ty vlastnosti které potřebuji zrovna na tom projektu ze kterým pracuji.

Komentář ze dne: 06.11.2009 13:16:17     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Re: Re: Rozdělil bych to Komentář: 1. "má FB možnost oddělit data od indexů do různých souborů?" Nemá, protože je to vcelku zbytečné. Tento způsob rozdělování I/O zátěže byl užitečný před 20 lety. Dnes lze s dostatkem RAM pro cache, SSD a/nebo moderními storage systémy dosáhnout mnohem lepších výsledků. 2. "má FB možnost pokročilých hintů?" Co to je ten "pokročilý hint"? Ve FB můžete specifikovat prováděcí plán, pokud vám nevyhovuje ten vybraný optimalizátorem. Navíc lze určité prvky plánu ovlivnit i způsobem formulace SQL dotazu, stačí jen vědět jak optimalizátor funguje. 3. "má FB možnost rozkládání zátěže?" Co si představujete pod pojmem "rozkládání zátěže"? Paralel I/O ? Paralelní zpracování částí dotazů? Rozdělování práce mezi více instancí? Nebo něco jiného? U FB lze při nasazení architektury Classic nebo SuperClassic dosáhnout mnoha scénářů rozkládání zátěže. Záleží na konkrétních požadavcích.

Komentář ze dne: 06.11.2009 13:33:33     Reagovat Autor: Jureckova Mail: @ Titulek: Re: Re: Re: Re: Rozdělil bych to Komentář: k 1 - he he, ho ho:) in-memory databaze jsou sice pekna vec, ale oddeleni dat a indexu je pro vykon jedna z nejpodstatnejsich vlasnosti. k 3 - zkuste mi napsat, jak firebird donutím k tomu, aby mi nad jednou databazi zpracoval analyticky dotaz nad nerovnomerne obsazenou tabulkou (klic treba rok, mesic) tak, aby mi vyuzil efektivne maximum jader / procesoru, ktere ma dany hardware k dispozici. To znamena, aby treba dle planu jedno jadro zpracovavalo dva mesice, kde je malo dat a tri jadra jeden mesic, kde je hodne dat.

Komentář ze dne: 06.11.2009 19:20:04     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Ad 1) Nemáte pravdu, ale očividně jste o svém názoru skálopevně přesvědčen. Nicméně přesvědčení bez důkazu samo o sobě není žádný argument (ani pokud je založeno na autoritativních poučkách starých 10 a více let). A in-memory databáze nejsou jedinou možností. Mimochodem, jak by vám oddělení indexů do samotného souboru pomohlo pokud máte vše na jediném diskovém poli? Problematika data placementu v rámci databáze se v projektu probírala již několikrát, a určitě se bude probírat i v budoucnu. Určité změny vnitřní struktury databáze mohou být přínosné, některé pouze marginálně a některé nikoliv. V rámci projektu se vždy snažíme nacházet takové úpravy, které jsou schopné přinést podstatnější pozitivní efekt (např. uložení BLOB popisovačů ortogonálně k řádkům apod.). Zatím nebylo prokázáno, že by separátní uložení indexů poskytlo oproti současnému způsobu zpracování jiné než zanedbatelné zlepšení, a to navíc jen za velmi specifické konfigurace SW/HW. Ad 2) Firebird v současnosti nepodporuje vnitřní paralelizaci částí dotazů. Protože 99% databázových operací je stejně disk-bound a nikoliv cpu-bound, tak pokud vám OS a HW nedodá relevantní části databáze včas, nic nezískáte. Samotné I/O je ve Firebirdu *velmi* efektivní, ale neustále se pracuje na dalších vylepšeních celého cache + disk I/O subsystému. Později možná přijde na řadu i paralelizace částí dotazů, ale zatím to není v plánu. Pokud máte tedy tak náročné OLAP požadavky, které *prokazatelně* taková paralelizace urychlí (potřebujete i adekvátní HW a OS), doporučuji v současnosti použít třeba Oracle nebo DB2. Nicméně takové požadavky rozhodně nemá každá aplikace / uživatel. Mimochodem rozdělení zátěže jednoho dotazu na více cpu/jader bude mít výraznější efekt pouze pokud systém nebude dělat nic jiného. Pokud v systému bude pracovat 200 dalších uživatelů, tak vám rozdělení může nadělat i více škody než užitku (synchronizace a přepínání kontextu také něco stojí, o čurbesu v cache nemluvě). Pozn. Firebird je samozřejmě schopen zpracovávat několik požadavků paralelně a zaměstnat více cpu (arch. Classic nebo SuperClassic, částečně i SuperServer).

Komentář ze dne: 06.11.2009 22:37:13     Reagovat Autor: Mail: @ Titulek: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Mimochodem, jak by vám oddělení indexů do samotného souboru pomohlo pokud máte vše na jediném diskovém poli? Nijak - proto se v enterprise segmentu používají samostatná pole pro data (a i tehdy dále dělené), pro indexy, tempy, undo apod. Ale chápu, že to pro vás narozdíl od vašich důkazů nejsou důkazy;-) Pokud je někdo omezen viděním světa na firebird, tak to asi nepochopí...

Komentář ze dne: 08.11.2009 16:39:55     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Nepochopil jste smysl mé poznámky. Účelem bylo poukázat na nutnost specifické konfigurace HW aby toto oddělení mělo vůbec smysl. Mimochodem, není nutné mít hned oddělená disková pole, úplně stačí i jednotlivé disky. Jinak u Firebirdu se pro high-end vždy doporučuje umístit databáze a oblast pro dočasné soubory na samostatná zařízení (undo FB nevyužívá). Oddělení dat a indexů by za stávající podoby struktury indexů a práce se stránkovou cache ničemu výrazně nepomohlo. Zato pouhé oddělení dočasných souborů má typicky výrazný pozitivní efekt na drtivou většinu aplikací. Dodal bych jen že mé vidění světa se neomezuje jen na Firebird. Pracoval jsem s mnoha databázovými systémy, a vždy jsem se zajímal i o taje jejich vnitřní práce a implementace, a stále se snažím držet si přehled (moje práce to do značné míry vyžaduje). Nicméně se na jejich vývoji přímo nepodílím, takže se necítím kompetentní se o nich vyjadřovat tak jako o Firebirdu, v jehož vývoji jsem zapojen už od začátku.

Komentář ze dne: 06.11.2009 20:31:25     Reagovat Autor: stehule Mail: @ Titulek: Re: Re: Re: Re: Rozdělil bych to Komentář: na embeded verze normalnich velkych databazi se vsichni SQL vendori uz vybodli. tahle oblast se prenechala specializovanym produktum. oddeleni tablespace s indexama od dat je naprosta nutnost, uz jen z toho duvodu ze se pro indexy dava vetsi cache nez pro data a jinak se nastavuje prefetch na diskovem poli. Docete se to v kazde prirucce o optimalizaci oraclu nebo db2.

Komentář ze dne: 06.11.2009 21:56:06     Reagovat Autor: Pavel Stehule Mail: @ Titulek: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Sice jsem vcera posilal komentar - nicmene nikoliv tento. Marku nemas problem se systemem?

Komentář ze dne: 07.11.2009 14:08:06     Reagovat Autor: Marek Kocan Mail: marek.kocan@dbsvet.cz Titulek: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Ahoj Pavle, chápu dobře, že jsi něco postoval a nezobrazuje se to (nemuselo projit antispamem) a současně se někdo podepsal jako ty? KER

Komentář ze dne: 07.11.2009 17:43:32     Reagovat Autor: Pavel Stehule Mail: stehule@kix.fsv.cvut.cz Titulek: Re: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Presne tak Pavel

Komentář ze dne: 07.11.2009 20:30:02     Reagovat Autor: Marek Kocan Mail: mare Titulek: Re: Re: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Težko říct, na chybu to nevypadá, to, že se za Tebe někdo podepsal, bohužel nemáme jak ovlivnit. Jiná otázka je, proč chybí příspěvek - pokud prošel AnO filtrem, tak bychom jej měli mít v databázi k antispamovému filtru, ale tam není. Čili ano, mohla se stát nějaká chybka, ale nevidím nic nezvyklého. Nejpravděpodobnější vidím problém s AnO. --KER

Komentář ze dne: 08.11.2009 07:06:27     Reagovat Autor: Pavel Stehule Mail: stehule@kix.fsv.cvut.cz Titulek: Re: Re: Re: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Možnost, že jsem se přepsal, tu samozřejmě, že je. Ale nestalo se mi to poprvé. Pro záznam, ten příspěvek podepsaný jako "Stehule" jsem nenapsal. Očekávat vlastnosti plně funkční db u databáze, která se, kromě jiného, používá jako embeded, je holý nesmysl. Až bude možné Oracle nebo DB2 nainstalovat během 0.00sec a Express edice budou menší než 5MB tak ano, ale do té doby je to hloupé. Navíc, bavit se o nejhorší databázi, v době, kdy 80% programátorů neumí pořádně napsat rychlou datově orientovanou aplikaci je nářek na špatném hrobě. p.s. Pro Pavla Císaře - PostgreSQL není a nebude embeded databází - není navržena jako embeded databáze, a je deklarováno (v FAQ), že nemá a nebude mít vlastnosti embeded db. Tudíž vytýkat pg nedostatek embeded fíčur je +/- totéž jako vytýkat Firebirdu nedostatek analytických VLDB funkcí.

Komentář ze dne: 08.11.2009 15:46:16     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: "Navíc, bavit se o nejhorší databázi, v době, kdy 80% programátorů neumí pořádně napsat rychlou datově orientovanou aplikaci je nářek na špatném hrobě." Amen. "PostgreSQL není a nebude embeded databází - není navržena jako embeded databáze, a je deklarováno (v FAQ), že nemá a nebude mít vlastnosti embeded db. Tudíž vytýkat pg nedostatek embeded fíčur je +/- totéž jako vytýkat Firebirdu nedostatek analytických VLDB funkcí." Já ty důvody znám a plně je chápu. To o co šlo bylo vypíchnout právě pofidérnost srovnávání "bullet listů" s vlastnostmi. Vlastnosti *kvalitu* produktu nijak nedefinují, pouze určují oblasti vhodného použití. Firebird si zakládá na kompaktnosti a vertikální škálovatelnosti, PG zase na objektovosti a vnitřní modularitě která se projevuje v podpoře specifických datových typů, struktur nebo jazyků. PG nikdy nebude tak kompaktní a škálovatelná jako FB, protože by tím přišla o svou jedinečnou podstatu, a FB nikdy nebude tak modulární jako PG, protože by ztratil svoji kompaktnost. Jen tak na okraj, zde (http://www.firebirdnews.org/?p=3759) je zajímavé srovnání (TPC-B) mezi FB, PG a MySQL.

Komentář ze dne: 08.11.2009 16:13:39     Reagovat Autor: Pavel Císař Mail: pcisar@ibphoenix.cz Titulek: Re: Re: Re: Re: Re: Rozdělil bych to Komentář: Ano, člověk se to dočte nejen v těchto příručkách, a nikoliv, není to nutnost :-) Je to jen další sada "šoupátek" kterými se dá zakvrdlat, a občas i něco málo urychlit. Problém je v tom, že tahle šoupátka jsou pro běžnou potřebu příliš obecná, sama o sobě (bez správného vyladění dalších faktorů) nic neřeší, jejich správné použití je vždy individuální a vyžaduje dobrou znalost vnitřní práce serveru i HW/SW prostředí. Jinými slovy, v rukou odborníka *může* za jistých okolností *napomoci* (spolu s dalšími nastaveními) k lepšímu výkonu *specifických* operací. Zároveň má ale i své důsledky, tzn. že je to jen další kompromis který při vylaďování systému můžete udělat. Situace, kdy toto oddělení je *jedinou* možností jak dosáhnout požadovaného výsledku je velmi vzácná (pokud budeme brát v úvahu, že datové sklady v řádu terabajtů tvoří jen zlomek tisíciny procenta všech databázových aplikací), většinou si člověk vystačí s jinými prostředky. Bohužel poučka o oddělení indexů od dat je natolik zakořeněná mezi "laickou" veřejností, že je téměř považována za naprostou nutnost s každodenním použitím, což není. Z toho důvodu je zatím na ocasu důležitosti při vývoji Firebirdu, protože např. lepší vnitřní struktura databáze nebo vylepšení práce s cache obecně zvýší efektivitu práce všech aplikací bez rozdílu, a většinou i o mnohem více.

Komentář ze dne: 05.11.2009 10:59:06     Reagovat Autor: Robo Paterka Mail: robopaterka@seznam.cz Titulek: re Komentář: pracoval som s ORACLE, DB2, MS SQL, bral data z Sybase, SQL,Informixu a pracujem teraz s db platformou SaS , ktorú považujem za najhoršiu,(otrasný management, špecifický SQL, netransakčné spracovanie dat, bláznivé licencovanie...) jediné pozitívum je klient jeho štatistická stránka (ale v praxi takmer nepouživaná) s pozdravom robopaterka@seznam.cz

Komentář ze dne: 05.11.2009 11:04:06     Reagovat Autor: Mail: @ Titulek: Re: re Komentář: Sas je snad primárně OLAP nebo ne?

Komentář ze dne: 05.11.2009 11:31:43     Reagovat Autor: Jarmil Nový Mail: @ Titulek: SQL od MS Komentář: Jednoznačně za nejhorší považuju SQL z dílny Microsoftu. A není to jen můj názor, navíc není nijak fanatický, operační systémy využíváme výhradně od Microsoftu, ale museli jsme přejít k Oracle - výkonově ani kvalitativně prostě SQL nezvládal.

Komentář ze dne: 05.11.2009 12:15:22     Reagovat Autor: DEE Mail: @ Titulek: Komentář: No zajímalo by mě kolik z těch co tady plivou na MS SQL server ho opravdu někdy nasazovalo. Taky nikdo, ze zde diskutujících "plivařů", nezmínil verzi SQL Serveru, byť zrovna z hlediska bezpečnostních i jiných "problémů" je mezi nimi docela rozdíl. Pokud bych měl hodnotit balík, který dostanu při zakoupení produktu a odhlédnout tak od samotného db stroje, tak bych mezi ty horší postavil klidně i Oracle. Pokud nepoužiji vlastní nástroje, tak to co se dodává "v balíku" není zrovna moc dobře použitelné. V tomto ohledu zase vyniká SQL Server. Obecně se snažím jednotlivé DB platformy nerozlišovat na nejhorší nebo nejlepší. Často totiž nemáte moc na výběr a DB platforma je silně spjata s celkovým řešením (třeba provoz SharePoint Portal Serveru na Oracle?). Takže nejhorší db platforma? Odpověď je "Jak na co a v jak kterých podmínkách".

Komentář ze dne: 05.11.2009 12:52:15     Reagovat Autor: Jarmil Nový Mail: @ Titulek: Re: Komentář: Já doplním za nás - 2005, 2008. Byť jde o dvě nejnovější verze, obě mají řadu problémů pro praktické nasazení v enterprise segmentu. Tam se nehraje na žádná klikátka. Ale ani ty klikátka Microsoft pořádně neumí - narosto náhodné chyby, neschopnost opravovat chyby apod. A to co se dodává k Oracle databázím standardně funguje docela dobře, bez chyb. Tak nevím, nejste někdo od MS?:-)

Komentář ze dne: 05.11.2009 18:13:49     Reagovat Autor: DEE Mail: @ Titulek: Re: Re: Komentář: :-). No sranda musí být i kdyby na chleba nebylo. Od Microsoftu opravdu nejsem a byť to z mého příspěvku asi přímo nevyplývá, jako komerční db platformu preferuji Oracle. Na druhou stranu jsem zastáncem homogenních řešení. Tzn. pokud mám na serverech jen Wokna, provozuji Win doménu, na klientech samozřejmě taky Wokna, tak nevidím důvod proč nezvolit jako db právě MS SQL Server, který je velice dobře integrován a jeho administrační nástroje se chovají a vypadají jako jiné made by Mrkvosoft. Pokud bude byť jen jediný server Unixový, popřípadě některý z provozovaných systémů bude vyžadovat nebo umožňovat snadný přechod na Oracle, pak prioritně hlasuji pro jeho využití. Ono je snadné mluvit o tom co, kdo, a taky kde by chtěl nasadit, jenže to všechno je i o penězích. Pokud máte ve firmě (organizaci) alespoň jeden IS stavěný tzv. "na míru", může vás migrace na jinou db platformu přijít pěkně draho. Nemluvě o licencích na db platformu jako takovou. Je asi zbytečné zde o tom polemizovat. Každý co tady píše už urpěl nějaké ty zkušenosti a podle toho se také v praxi chová. Nebo v to alespoň doufám.

Komentář ze dne: 05.11.2009 13:21:06     Reagovat Autor: fredy Mail: @ Titulek: MSSQL Komentář: Po tazkej reklamnej masazi, som sa pokusil pouzit MSSQL v ERP pre male firmy, bola to hroza. Neskutocne pomale, komplikovane... a drahe.

Komentář ze dne: 05.11.2009 13:42:44     Reagovat Autor: Mail: @ Titulek: Re: MSSQL Komentář: Ano, to je jediné, co MS v databázích ovládá - díky prachům marketingové oblbování.

Komentář ze dne: 27.11.2009 15:54:34     Reagovat Autor: Jan Gregor Mail: hohohohonza@seznam.cz Titulek: Nelze vybrat nejhorsi databazi Komentář: Tedy uz cela otazka mi prijde trochu nesmyslna. Copak muzete pomerovat treba uz vyse zminenou embedded DB (kdyz uz ne FB tak treba SQLite) s Oraclem ? Co takhle se zacit bavit alespon v ramci kategorii ? Je sice pravda, ze MSSQL databaze ma sve mouchy, ale ze by byla zas tak spatna jak zde vsichni zminujete? Zase zalezi jak na co... Ja ji mam v jednom eshopu (btw: rychlost vyvoje specialne v .NET + MSSQL je mnohem vyssi nez s Oracle apod.). Mame cca 450 tisic zakazniku, datovy soubor ma nyni cca 1,3 GB. Na Oraclu to sice bezelo o neco rychleji (stejne dotazy, podobne indexy), ale proc me to ma zajimat, kdyz je rozdil v 80% pripadu v radu jednotek procent ? Navic ... kdyz uz by me zajimalo (tzn. byl by to realny problem, kterym bych se musel zabyvat), optimalizaci na jedne platforme dosahnu vetsi rychlosti nez prostou migraci. Na zaver ... MSSQL sice asi neni vhodnou db pro data o velikosti desitek GB, ale na to, co asi vetsina z nas dela, bohate staci.

Komentář ze dne: 02.12.2009 16:29:32     Reagovat Autor: Michal Barcik Mail: bertik@chello.sk Titulek: MS SQL Komentář: To ze MS SQL DB nie je vhodna na viac ako par GB...zalezi na implementacii a na tom ako ho pouzijes. Parcival som na malych databazach (radovo 100 - 200 GB) a uz na MS SQL 2000 s tym nebol z hladiska performance prblem. Jediny problem bol v delevoperoch, krori kodili nskutocne dotazy a selekty a kurzory.. Priklanam sa k nazoru ze neexisuje v skutocnosti zly DB system, existuju len obmedzeny ludia ktory nevedia vyuzit vlastnosti systemu naplno a potom sa tvaria ze za to moze system ;)

Komentář ze dne: 15.12.2009 13:38:49     Reagovat Autor: TDI Mail: tomas.dittrich@gmail.com Titulek: Re: MS SQL Komentář: Souhlasím s názorem, že odsoudit jakoukoliv db platformu je špatné. Každá se většinou zaměřuje na jiný sektor uživatelů. Většinou to dělají lidé neznalí (příspěvky typu odzkoušel jsem x db platforem a tahle je špatná či jedině tahle byla použitelná a o žádný jiný už nechci slyšet). Než se stane člověk dané oblasti profesionálem a má danou technologii (platformu) v malíčku to trvá i roky. Souhlasím s dvěma názory, které tu zazněly a to že je to většinou o lidech jak programátorech, tak systémových administrátorech. Jsem zastáncem názoru, že člověk se může zaměřit profesionálně buď na vývoj nebo administraci, ale obojí nezvládne obvzláštně u tak rozsáhlých produktů jako je MS SQL Server, Oracle apod. A pokud nebudou tyto činnosti odváděny na profesionální úrovni, nebude nebude žádný db produkt vyhovující. Stejně tak bych vám tu mohl povídat zážitky od lidí co se věnují výhradně Oracle, jaké mají problémy, kde hlavní roli hraje neznalost lidí a neochota se učit novým věcem. Mám praktické zkušenosti s MS SQL Server i na velmi rozsáhlé IS, kde DB mají desítky až stovky GB. A jde to. Stejně tak by to šlo s Oracle, DB2 apod. ale ne bez kvalifikovaných lidí.

Komentář ze dne: 23.12.2009 18:38:51     Reagovat Autor: geneticy Mail: gw4@volny.cz Titulek: Souhlas Komentář: Tak s tímhle souhlasím. Porovnívat lze jedině tehdy, umíte-li vyždímat z daného systému maximum jak po stránce administrace - tak vývoje aplikací. Jinak se bavíme ryze akademicky a každý bude vychvalovat to, s čím se sžil a bude totéž hledat i jinde - což je omyl.:). Přechod na jinou platformu znamená často myslet jinak a předchozí zkušenosti mohou být často zavádějící. V případě DB platí pro normální (nikoliv geniální) jedince - čím více DB znáš, tím zřejmě hůře - protože kromě jednoho systému znáš pravděpodobně ty další jen povrchně. Nelze totiž tvrdit u normálních (nikoliv geniálních) jedinců, že stoprocentně ovládají Oracle, MSSQL, Fiebird, PG a MySQL současně. I dobrý databázista na jednom systému při přechodu na jiný se musí moc učit.:).

Komentář ze dne: 18.01.2010 15:29:33     Reagovat Autor: xhejduka Mail: @ Titulek: Re: Souhlas Komentář: Souhlas, není co dodat. Demagogie tytu tahle db je nejhorší je nesmysl.

Přidat nový komentář

Zobraz článek Diskuse::Která platforma je nejhorší?