Jak odvrátit zánik RDBMS

7. 6. 2016 6:21 (aktualizováno) | Michal Šalko

Jak odumírá svět RDBMS

Asi už 10 let sleduji vývoj,  jak s novou nastupující generací programátorů klesá úroveň znalostí a dovedností práci s databázemi. Vidím upřednostňování nenormalizovaných forem ukládaní dat pomocí XML a JSON, nebo jiných nenormalizovaných formátů. Myslím, že důvod jejich existence a to uchovávaní velkého množství různých typů informací nad určitými formami se absolutizuje.  S tím jak roste výkon a klesá cena hardware, tak už je neekonomické dát si práci s FDM (fyzickým datovým modelem) a zabezpečení integrity dat je ponecháváno na aplikační úrovni.

Výběry dat se realizují hlavně přímo nad kompozitními daty (XML nebo JSON) a to pomocí NoSQL databází, nebo pomocí kompositních datových typů v RDBMS(Relačních databází).

K slovu přichází ERD (Entito- relační diagram) nutně pouze v případě velikého objemu dat, kdy ani brutální sila hardware nepostačuje rýchlosti výběru nebo zpracování dat.

A klasické RDBMS opět ostrouhají. Na scéně se objevují alternatívy se sloupcovými databázemi v případě datových skladů, nebo proudnicovými databázemi v případě on-line statistického zpracování dat. Protože jsou rychlejší.

Táto úvaha je určen všem těm, kteří ještě neztratili buďto víru v RDBMS jako já, nebo ji ještě nezískali. Často špatně navržený fyzický datový model, který neodpovídá potřebám aplikací a schopnostem databáze naše odpůrce ještě utvrzuje v tom, že RDBMS je už skoro na odpis a slabým plus je, že umí dělat v transakcích.

Agilní programování a ORM (Objektovo-relační mapování)

Často se potkávám u dnešních programátorů s agilním vývojem. Pod tím slovem rozumím to, že souhrn požadavků není jasně ukončen a v průběhu vývoje se upřesňuje mění a to i celkem zásadním způsobem. To má vliv i na datový model, který je hodně dynamicko-statický. Dynamický v tom, že se musí měnit. A statický v tom, že aplikační programátoři jsou navztekaný.

Jejich problémem je ORM. Názor „DM super, ale mi již máme naprogramované ORM.“  Znamená to, že můžeme hýbat pouze s částí datového modelu, prože programátoři prostě již něco mají hotovo a nechtějí nic předělávat. Asi nejhorší zlo je ORM, které používá mapování na entity (rozuměj fyzické tabulky v databází). Pak už s FDM (fyzickým datovým modelem) nemůžete nic dělat aniž by to pánové aplikační programátoři neodsouhlasili a přitom nezačali naříkat, že oni to musí upravit támhle a jinde zase tudle.A proč by to nemělo být už jednou tak, když to funguje.

Dalším hřebíčkem do rakve ERD(entitno relační diagram) je, když programátoři puritáni generují databázi z ORM metadat. Sice metadata mohou upravovat, ale proč by si s tím dělali těžkou hlavu? Dokud vy dbáte o nějaké pojmenování databázových objektů, které v případě výskytu chyby identifikují kde co nastalo, tak aplikačním programátorům je to jedno. Oni vidí a nachází chyby na aplikační úrovni. Větší zlo je to, že datový model se takto staví ze spod. Znamená to,že aplikační programátoři vidí jednotlivé stromy, ale nevidí les.

Tatam je doba, kdy aplikační programátoři používali DAO (Data access object – abstraktní interface nad databází ) vrstvu s SQL jazykem. Nyní je vše automatizováno s jednoduchým kalkulem jedna tabulka je jedna třída.

Jak agilní programování sloučit s SQL jazykem

Položil jsem si otázku, jak můžu odstínit šílení aplikačních programátorů před FDM, kteří potřebuje změnu jako sůl ?

Před 6 roky jsem měl obdobný problém na MySQL a vyřešil jsem je jednoduše tím, že ORM jsem posunul na server.  Přístup na fyzická data přímo nebyl, ale byl přístup k procedurám pro insert, update, delete a select. Procedura přímo v sobě obsahovala SQL příkazy, které dle parametrů provedli dotaz a vraceli výsledek. MySQL umožňoval navíc vracet i několik recordsetů což bylo super, když bylo potřeba načíst nějaká složitější formulářová data. Já jsem měl pak možnost měnit pod rukama programátorů fyzický datový model tak , jak bylo potřeba vzhledem k požadavkům na databázi nebo jak to vyžadovala databáze sama.

Je pravda že databáze pro řízení výroby obsahovala kolem 100 tabulek a procedur tam bylo kolem 400. Ale fungovalo to.

Bohužel dnes je to jinak a prostor pro FDM není. Když jsem nastínil řešení tohoto problému před 2 lety aplikačním programátorům, tak jsem dostal jednoznačnou odpověď mi tak tak rozumíme SQL a ty si jediný, který umí PLSQL jazyk. A tak raději se volají funkce v ORM.

Hm. Studentka za půlroku to celkem zvládla bez problémů. Procedurální jazyk není až tak složitý. Záleží na ochotě.

Jak navrhovat datový model ?

Myslím si, že FDM je správný tehdy, když je aplikačně neutrální. Můžete přistoupit z jakéhokoliv místa a ona vrátí korektní data a přitom zabezpečí sama jak referenční, tak i datovou integritu a obchodní pravidla. Horší je když aplikační programátoři to realizují pouze na aplikační vrstvě. Pak databáze slouží jako hromádka různých dat.

A jak na datový model? Velice jednoduše. Od konceptuálního po ERD. Entitno relační model by měl být komunikační model mezi aplikačními programátoři a databázistama. Ideálním řešením je, když DAO vrstva není fyzicky mapována na FDM , ale na ERD. To umožňuje databázistům měnit strukturu FDM tak, aby odpovídal požadavkům na databázi.

Aplikační programátoři mají jednu nepříjemnou tendenci. Přizpůsobovat  datový model potřebám aplikace. Tak vzniká mnohdy reduntance dat a servisní tabulky. V případě, ale že se domluvíte na rozhraní v DAO vrstvě, tak programátorům můžete poskytnout požadovaná data, nebo provést požadované operace přímo nad FDM, aniž by Jste je tím zatěžovali.

A tak když odstíníte aplikační programátory od fyzického datového modelu tak můžete normalizovat nebo denormalizovat dle výkonu databáze. A implementovat integritu dat a obchodní pravidla. A vypálit odpůrcům SQL a RDBMS rybník.

A spíše normalizovat. :)

  • 6. 6. 2016 9:55

    MMN (neregistrovaný) 130.233.143.---

    Au au au, to se nedá číst.

  • 6. 6. 2016 10:03

    pneptun2 (neregistrovaný) 109.75.156.---

    Cheche, takhle frustrovanej clanek uz tu dlouho nebyl :-D nejlepsi je jak z nej dejcha "mlady sou liny fracci, ja tomu rozumim nejlip!" :-DDD

  • 6. 6. 2016 10:45

    kvr kvr

    Jenže ono je to tak v pořádku.

    Databáze je tu proto, aby sloužila aplikaci pro uložení dat a umožnila k nim snadný přístup. Nic víc se od ní nechce a splňuje tak svůj účel.

    Doba, kdy databáze poskytovala (relativně k ostatním) slušný jazyk je dávno pryč. Nulová abstrakce, žádná bezpečnost (per object/row, per table je naprosto k ničemu), vyjadřovací schopnosti jsou sice silné z hlediska query, ale jinak naprosto nekompatibilní a nečitelné (přiřazení do proměnné, nepovinné použití aliasů - není vidět zdroj dat, atd.). A je naprosto jedno, jestli mluvíme o Oracle, MSSQL, DB2, PostgreSql, principy, kde selhávají, jsou všude stejné. V DB vrstvě řešíme pouze něco, co potřebuje enormní množství dat, aby vrátilo relativně malý výstup - kde by se neefektivita přenosu do aplikačního významně projevila. Ale pak zase rychle pryč.

    Takže se jde o úroveň výš, na aplikační server, kde se všechny uvedené věci řeší velice snadno. Data jsou data a pro vývojáře je otázkou lusknutí prstů, jestli budou v SQL, NoSQL, Hadoop, Elastic nebo někde v cloud ve zcela neznámém formátu na neznámém místě. Samozřejmě stále musí splňovat nějaké kritéria na snadný přístup a rychlé vyhledávání, což je u zmiňovaných příkladů s XML/JSON s otazníkem. Ale jinak je to úplně jedno.

    Databáze jako vývojářská platforma a středobod informačního systému je mrtvá od doby, co se běžně začala používat 3+-vrstvá architektura, což je už minimálně 15 let.

  • 6. 6. 2016 10:55

    Ten češtin (neregistrovaný) 195.113.97.---

    Prosím autora, aby si v příspěvku opravil pravopisné chyby. Děkuji.

  • 6. 6. 2016 11:29

    El Bucho (neregistrovaný) 77.240.103.---

    Co jsou ksakru proudnicové databáze? Tady už chybí akorát klasiky jako SŘBD (Systém řízení báze dat, DBMS)...

  • 6. 6. 2016 11:34

    Ivan Nový (neregistrovaný) 85.135.69.---

    To déle, proto se vlastně databáze zaváděly, aby se od sebe oddělil konceptuální, logický a fyzický pohled na data. A tyto pohledy by měly být na sobě nezávislé. Je fakt, že s rozšířením PC a XBase systémů se na to trochu zapomnělo.

    Předtím funkci logické vrstvy databáze suplovaly indexy a ještě předtím třídění souborů. Což se nám dnes na logické úrovni vrací v podobě funkcionálního programování :-)

  • 6. 6. 2016 11:39

    fotobaBA

    Príde mi to ako článok o výroku Linusa aplikovaného na databazy
    Jaderné noviny - 14. 4. 2016:
    Citáty týdne

    Je to nemoc rozšířená mezi lidmi, kteří studovali informatiku. Lidi si myslí, že „návrh s ohledem na budoucí rozšiřování“ je dobrý nápad.

    Je to _příšerný_ nápad.

    Pokud si myslíte, že „návrh s ohledem na budoucí rozšiřování“ je dobrý nápad, vlastně tím říkáte: „Já nevím, co chci dělat.“

    -Linus Torvalds
    http://www.abclinuxu.cz/clanky/jaderne-noviny-14.-4.-2016-sledovane-body-s-bpf

    resp. originál

    Quotes of the week

    This is a disease among people who have been taught computer science. People think that "designing with extensions in mind" is a good idea.

    It's a _horrible_ idea.

    If you think that "design with extensions in mind" is a good idea, you're basically saying "I don't know what I might want to do".
    — Linus Torvalds
    https://lwn.net/Articles/682943/

  • 6. 6. 2016 12:06

    bez přezdívky

    Jenomže "I don't know what I might want to do" poměrně dobře vystihuje realitu.

    Tedy realitu 95% programátorů kteří dělají něco pro někoho jiného.

  • 6. 6. 2016 12:20

    Peva (neregistrovaný) 193.86.239.---

    A já myslim, že je to jinak...
    LIdé i firmy nějak zapomněli na to, že i samotná data mají nějakou hodnotu a cenu a někdy dost vysokou. A proto by v nich měl být řád a pořádek. A k tomu DBMS aktivně napomáhá. Zákazníci dělají chybu, že přestali na toto hlesiko hledět, Koukají pouze na funkčnost a na data zapomínají...­.Programátoři jen dělají to co zákazník chce a platí.

  • 6. 6. 2016 12:37

    MarSik (neregistrovaný) ---.redhat.com

    <cite>
    Můžete přistoupit z jakéhokoliv místa a ona vrátí korektní data a přitom zabezpečí sama jak referenční, tak i datovou integritu a obchodní pravidla. Horší je když aplikační programátoři to realizují pouze na aplikační vrstvě. Pak databáze slouží jako hromádka různých dat.
    </cite>

    A jak ta databáze asi zajistí integritu a obchodní pravidla, když dnešní aplikace jsou:

    1) distribuované (a single-point-of-failure kvůli relační databázi je problém)
    2) používají více než jeden zdroj dat.

    Jak už tu někdo poznamenal, ta doba, kdy veškerá logika a data aplikace byly v jedné databázi, je dávno pryč.

  • 6. 6. 2016 12:38

    Ivan Nový (neregistrovaný) 85.135.69.---

    Co to je pořádek v datech? Nemožnost získat z nich údaje, se kterými se předem nepočítalo? Nebo pořádek v datech = 3NF, 4NF, 5NF ? Každá sranda ale něco stojí.

    Data sama o sobě žádnou cenu nemají, cenu má jen jejich interpretace.

  • 6. 6. 2016 12:57

    dustin (neregistrovaný) ---.insite.cz

    Pokud je projekt živý, tak ani zadavatel neví, co bude potřeba za měsíc.

  • 6. 6. 2016 13:03

    Karel (neregistrovaný) 93.90.162.---

    Já to vidím trochu jinak. Ubývá chybných použití RDBMS. To je dobrá věc. RDBMS neslouží k ukládání dat, na to jsou DBMS. To jediné písmenko R je zásadní rozdíl. Typicky právě ORM je něco, co do RDBMS nepatří. Pokud někdo použije ORM a jako databázi Oracle, PostgreSQL nebo MySQL, tak je tam něco špatně.

    RDBMS je o tom, jak efektivně zpracovávat data. Pokud něčí aplikace data pouze ukládá a čte, tak je jen dobře, že se nezatěžuje s RDBMS. Problém vídím spíše u lidí, kteří data zpracovávat potřebují, ale RDBMS nepoužijí. Chlubí se výkonným clusterem, který jim spravuje "big data". Přitom typická RDBMS jim to vyřeší s prstem v nose na průměrném HW. Tedy pokud správně navrhnou datový model, což většina laiků neumí.

  • 6. 6. 2016 13:26

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Linus je mimo realitu.

    Něco podobného napsal o paralelismu. (A o C++ taky, respketive spíš o OOP)

    Pak napíše todle.

    Sorry, ale Linus už je asi ve fázi demence. Za prvné, zákazník neví co vlastně chce a zjišťuje to postupně, takže rozšiřitelnost je naprosto klíčová vlastnost systému (pro zachování příčetnosti implementátorů a zákazníka ostatně taky).

    Za druhé, osobní projekty díky nedostatku času dělám inkrementálně. Udělám nějaký funkční základ a poté do něj postupně přidávám podle toho jak mám čas a jak mám nápady přičemž priorita je udělat minimální fungující projekt co nejdřív. Dělání něčeho 5 let jen abych pak zjistil že už to nepotřebuju, ne díky.

    Linusi si debil :(

  • 6. 6. 2016 13:33

    Peva (neregistrovaný) 193.86.239.---

    Ano, máte pravdu v tom, že cenu má interpretace dat. Čím je horší, nejednoznačnější a nejasnější interpretace dat, tím jsou data v horším stavu a mají menší hodnotu. Nejvíce to zákazník pozná, až když chce migrovat z jednoho systému do druhého, protože předchozí systém/dodavetel skončil. Pak se nejlépe pozná, co je to mít pořádek v datech, Bohužel na to příjde zákazník až s křížkem po funuse. V době, kdy zadává požadavky na funkcionalitu, toto zpravidla neřeší.

  • 6. 6. 2016 13:42

    b*d (neregistrovaný) ---.zanox.com

    Začněme něčím jednoduchým, jako je třídění. Množina velikosti jednoho tisíce záznamů, možná dneska už tisíce záznamů, tříděná na databázi? Proč by měl uživatel dělat dotaz na server, co převede http požadavek na SQL a pošle na databázi? Setřídění v Javascriptu je prakticky okamžité. Odezva aplikace to je oč tu běží. Lidi jsou ochotní tolerovat dobře vykomunikovanou inkonzistenci, než totální fail nebo pomalou odpověď.

  • 6. 6. 2016 13:52

    Inkvizitor (neregistrovaný) 62.168.12.---

    Linus ten výrok publikoval v nějakém kontextu (dá se dohledat, není to těžké). Rozhodně neříkal, že nikdy nikde není vhodné mít API otevřené potenciálnímu rozšíření aplikace). Mimo jiné v tom postu píše:

    So unless there is a clear use-case, and clear semantics that people can agree on as being truly generic and useful for a lot of different cases, excuse me for being less than impressed.

    Takže jsi ze sebe udělal debile Ty, Čumile.

    Mimochodem, ta Recaptcha je bezva. "Verification expired. Check the checkbox again."

  • 6. 6. 2016 13:53

    Inkvizitor (neregistrovaný) 62.168.12.---

    debile -> debila, sorry

  • 6. 6. 2016 14:10

    MarSik (neregistrovaný) ---.redhat.com

    Zase.. typická RDBMS to vyřeší, ale musí mít ty data. A dneska je obvykle nemá, protože se linkují data z různých distribuovaných zdrojů. Cizí klíče také neumí překlenout propast mezi servery nebo zdroji dat... takže se o integritu stará aplikace. Ve spojení s optimistic locking a eventual consistency je to i dost rychlé a výkonné a degraduje to postupně (např: Chybí server se skladem? No tak ukážeme jen ceny než se zase objeví.).

    Běžné RDBMS prostě nejsou stavěné na distribuovaný provoz i když master/slave nebo master/master replikaci v nějaké formě obvykle umí.

    Máte nicméně pravdu v tom, že na spoustu dat stačí CRUD a síla relační databáze není potřeba. Ono se tedy třeba MySQL dá používat i bez cizích klíčů.. MyISAM je stejně neumí (nebo už ano?).

  • 6. 6. 2016 14:12

    Tomaš (neregistrovaný) 62.197.195.---

    Podľa mňa ma RDBMS stále zmysel a stále ho aj bude mať.
    Sú veci na ktoré je určena a vedie si tam dobre. Rovnako ked niekto stavia ORM nad RDBMS len preto že nevie SQL alebo PL/SQL je alibizmus. Dobrý programator by mal vediet viac programovacích jazykov.

  • 6. 6. 2016 14:45

    Zdenek Mazanec (neregistrovaný) 89.190.50.---

    To si urcite delate legraci ze? Tridit radeji v javascriptu v prohlizeci uzivatele misto v databazi, ktera je na to stavena je podle me naprosto silena myslenka.
    Uz docela chapu, kam se ztraci vykon pokud tohle programatori web aplikaci skutecne delaji. Pocitace o rady rychlejsi, ale uzivatelsky dojem stejny nebo horsi nez v dobe windows 3.11.

  • 6. 6. 2016 15:25

    bez přezdívky

    Tak jsem to myslel - je to realita z hlediska zadavatele. Programátor už pak nic nevymyslí - jen může odhadovat budoucnost na základě svých zkušeností.

  • 6. 6. 2016 15:50

    pneptun2 (neregistrovaný) 109.75.156.---

    Ckej ale takhle to presne linus myslel rek bych. Proste to napises jednoduse, tak aby to minimalne funkcne vyhovovalo misto abys hned na zacatku stavel jaderny elektrarny. a kdyz se objevi novej pozadavek kterej tam nejde vtlouct tak refaktorujes (a menis api, ale to se holt ve vyvoji stava - dobrej priklad je angular vs angular2 kde nezustal kamen na kameni napr nebo nemenis ale pridavas a bobtnas jako napr kdysi awt a swing :-D

  • 6. 6. 2016 17:51

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Ano geniální, takže skončíš tak že budeš celí dni jen refaktorovat. Možná u projektíku s 3K řádkama je to ok, u projektu s ~300K řádkama pro zákazníka už ale vážně ne.

  • 6. 6. 2016 17:57

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Ale sám si debil ...

    Vycházel sem z toho co bylo postnuto sem, celé znění jsem neměl absolutně chuť číst. Jeho leckdy stupidní názory jsem měl tu čest číst v minulosti (C++/OOP plus ten paralelismus) takže jsem očekával že ten zbytek bude stát stejně za hovno jako úryvek.

    Mimochodem, systémy se dělaj rozšiřitelné ve chvíli kdy se jejich rozšiřování očekává, takže pokud mu todle využití nevadí, pak se s celím tím svým rantem netrefil.

  • 6. 6. 2016 18:03

    Jan Forman

    Dle mého se srovnává nesrovnatelné. Univerzální řešení prostě neexistuje a pokud je třeba ukládat velké množství dat a rychle k nim přistupovat, RDBMS prostě není dobrá volba. Jedná se prostě o nástroje, a hřebík taky nebudu zabouchávat šroubovákem a přesto si nemyslím, že by šroubovák nebo kladivo přestalo existovat, protože ho druhý nástroj s jistými obtížemi také nahradí.

  • 6. 6. 2016 18:34

    Ivan Nový (neregistrovaný) ---.ip.nej.cz

    No vidíte a já měl dojem, že ORM se používá proto, aby šlo aplikaci beze změn používat s různými databázemi a různými strukturami fyzického uložení dat a stačilo jen vyměnit driver. Aby šlo optimalizovat uložení dat bez nutnosti upravovat aplikaci.

    Jinak pokud to tak není, tak v případě změny aplikace musíte přepisovat tisíce SQL příkazů, s aplikací ORM to stačí přepsat na jediném místě. Používat přímé SQL příkazy v aplikaci je sebevražda.

    Navíc pro kritická místa aplikace vám nic nebrání rozšířit model o metodu zajišťující optimalizovamý přístup k datům.

  • 6. 6. 2016 18:51

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    Neni, ono u OOP se ukazuje ze to neni zrovna idelani. Co se paralelismu tyce, tak tam nevim kontext, ale i tak se ukazuje ze stale na CPU je kolikrat efektivnejsi se mu vyhnout.

    To ohledne rozsiritelnosti ja spis chapu jako spekulativni obecnost. Jako ze nema smysl se az moc snazit vymyslet to ultra cool co nejvic nastavitelne, dynamicke, rozsiritelne. Jelikoz clovek stejne nakonec zjisti ze to co klient chce je jinak a stejne to nakonec nevyuzije jen mu to zabere spustu casu a penez.

  • 6. 6. 2016 19:15

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    No popravde sice nejsem zastance toho radit data na strane javascriptu, ale tak silene mi to neprijde. Napriklad nas DB server zpracovava okolo 14k dotazu za vterinu. No a ackoliv je mozna o rad rychlejsi (o cemz pochybuji) tak stale verim ze tech 14000 dotazu pokud bych predpokladal ze vsechny delaji razeni, podle me probehne pomaleji, nez pokud by se jen vratily data a ty se seradily na strane klienta.

  • 6. 6. 2016 19:19

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    Ba naopak, diky tomu ze to napises jednoduse a zbytecne to nezeslozitis, tak se ti ten projekt vleze na ty 3K radku misto tech 300K ;)

  • 6. 6. 2016 19:20

    Inkvizitor (neregistrovaný) ---.net.upcbroadband.cz

    Ano, jsi. Howgh.

  • 6. 6. 2016 19:23

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    JJ presne. Ackoliv to srovnani neni uplne idealni. Preci jen neni moc pripadu kdy nekdo zatlouka hrebik sroubovakem. To spis bych to vzal s druhe strany, ono jsou veci co se daji pribit rebikem ale bylo by lepsi je prisroubit vrutem a naopak :)

  • 6. 6. 2016 20:20

    Inkvizitor (neregistrovaný) ---.net.upcbroadband.cz

    No jo, jenže:

    1. Databáze obyčejně obsahuje potřebné indexy, takže to řazení se zase tak moc nedělá.

    2. Server má různé úrovně cache, takže často databáze nemusí dotaz dělat vůbec.

    3. Pokud máš třeba 100000 položek zboží a prohlížeč chce zobrazit 25 nejlevnějších, co má dělat to javascriptové řešení? Poslat do browseru hned všech 100000, ať už si to seřadí a pak si stránkuje sám? Asi ne, co?

    Zkrátka a dobře to "client-side" řešení vypadá na první pohled jako dobrý nápad (a ve velmi speciálních případech i může být), ale obecně je to úplná pitomost.

  • 6. 6. 2016 20:31

    Ivan Nový (neregistrovaný) ---.ip.nej.cz

    Víte co je ruský šroubovák? Kladivo :-)

  • 6. 6. 2016 21:10

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Do 300K se vecpe jednoduší informační systém. Hodně štěstí s cpaním ho do 3K.

    Asi nemáš zkušenosti z praxe. Tam opravdu není čas na nic, natožpak na zbytečné refaktoringy.

  • 6. 6. 2016 21:11

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Reakce o hovně ...

  • 6. 6. 2016 21:18

    čumil (neregistrovaný) ---.156.broadband14.iol.cz

    Kdyby se OOP skutečně používalo, nebyl by problém (nemyslím tu OOP parodii ve stylu C++/Javy/whatever).

    Někdy jo, někdy ne, záleží dost na návrhu.

    Ne. Pracoval jsem na projektu s 0 promyšleností rozšiřitelnosti a bylo to peklo, protože klient přicházel furt s něčím dalším (a tak se to hackovalo až to nakonec bylo celí úplně zhackovaný).

  • 6. 6. 2016 21:18

    Pavel Francírek (neregistrovaný) 91.219.246.---

    S relačními databázemi přicházím do styku od MS SQL 6.5, tj. téměř 20 let. A viděl jsem soustu použití, které s relacemi neměly nic společného. Ukládání sériových dat, asociativních polí klíč - hodnota, dokonce i binárních.
    A je jenom dobře, že se objevují nástroje, které jsou primárně určeny k práci s těmito daty a relačním databázím zůstane, co jejich jest.

  • 6. 6. 2016 21:54

    ehmmm (neregistrovaný) 185.99.118.---

    A tak ja si zase namlouvam, ze predrecnik uz ty data proste v tom javascriptu v prohlizeci ma a pak je asi opravdu zbytecne si o ne rikat znovu serveru, jenom proto, aby dostal stejna data jenom jinak setridena. Osobne bych tedy tu hranici videl nekde niz, rozhodne ne tisic zaznamu. Pracovat s tisici zaznamu v JS z programatorskeho pohledu jde, ale kdyz si predstavim, ze kazdy zaznam se promitne do nejake struktury v prohlizeci, to pak Firefox sezere celou RAM a musi byt radost to pouzivat.

  • 6. 6. 2016 22:33

    Notorius maximus (neregistrovaný) ---.ipv4.broadband.iol.cz

    Ten Torvaldsův výrok vůbec není autentický, v podobném smyslu se vyjádřili Chuck Moore, Alan Kay a jiní už v dobách, kdy za sebou Torvalds ještě tahal kačera. Podle tebe asi další debilové.

    Už jsem pracoval na spoustě projektů a problém byl obvykle v tom, že pokud někde byla nějaká rezerva nebo se počítalo s rozšířením, v praxi to nakonec nikdy nebylo využito nebo to stejně nestačilo. Ale zato bylo třeba rozšířit nebo ohnout něco, co bylo natvrdo zadělané, často poměrně zbytečně, protože zrovna u té části nikdo žádné rozšíření nepředpokládal. Zrovna jeden takový problém momentálně řeším. Kvůli tomu, že někdo předpokládal nějaké rozšíření, je daná věc napsána naprosto zbytečně komplikovaně a komplikuje se tím spousta jiných věcí, přestože dnes je nad slunce jasné, že zrovna toto nikdo nikdy už rozšiřovat nebude, protože pokrok se vydal jiným směrem. Je třeba přidat funkcionalitu, která by byla snadno dodělatelná, kdyby býval někdo neuvažoval nad rozšiřitelností té první věci a hned nevymyslel, jak se to asi bude implementovat, čímž to nechtěně totálně zazdil.

    A to je to, co je míněno těmi výroky: pište to tak, abyste si nevědomky nevytvářeli překážky a omezení, která neplynou ze zadání, ale nepokoušejte se předvídat budoucnost. Stejně se netrefíte, jen si vyrobíte hromadu zbytečných problému a na spoustu budoucích si zaděláte.

  • 6. 6. 2016 22:46

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    To bylo mysleno spis jako vtip :). Jinak nas informacni system je okolo 600K, takze samozrejme vim jake to je. No a co se casu a refaktoru tyce tak to je vzdycky boj. Jedni by furt chteli refaktorovat a druzi jim oponuji ze na to neni cas :).

  • 6. 6. 2016 22:49

    kozzi11 (neregistrovaný) ---.cust.nbox.cz

    JJ, to je presne to co si myslim. Ja jen chtel poukazat na to ze mohou byt situace kdy se to muze jevit jako lepsi reseni

Přidávat nové názory je zakázáno.

DigiZone.cz: Skylink Samsung EVO-S příští týden

Skylink Samsung EVO-S příští týden

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

Podnikatel.cz: Babišovi se nedá věřit, stěžovali si hospodští

Babišovi se nedá věřit, stěžovali si hospodští

Lupa.cz: Jak levné procesory změnily svět?

Jak levné procesory změnily svět?

Vitalia.cz: Jaký je rozdíl mezi brambůrky a chipsy?

Jaký je rozdíl mezi brambůrky a chipsy?

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

Vitalia.cz: Když všichni seli řepku, on vsadil na dýně

Když všichni seli řepku, on vsadil na dýně

Podnikatel.cz: Takhle se prodávají mražené potraviny

Takhle se prodávají mražené potraviny

DigiZone.cz: Ginx TV: pořad o počítačových hráčích

Ginx TV: pořad o počítačových hráčích

Lupa.cz: Další Češi si nechali vložit do těla čip

Další Češi si nechali vložit do těla čip

Lupa.cz: Hackeři mají data z půlmiliardy účtů Yahoo

Hackeři mají data z půlmiliardy účtů Yahoo

Podnikatel.cz: Kalousek chce odklad EET. Předvolební tah?

Kalousek chce odklad EET. Předvolební tah?

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

DigiZone.cz: Numan Two: rozhlasový přijímač s CD

Numan Two: rozhlasový přijímač s CD

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

DigiZone.cz: Funbox 4K v DVB-T2 má ostrý provoz

Funbox 4K v DVB-T2 má ostrý provoz

Vitalia.cz: Inspekce našla nelegální sklad v SAPĚ. Zase

Inspekce našla nelegální sklad v SAPĚ. Zase

DigiZone.cz: Rapl: seriál, který vás smíří s ČT

Rapl: seriál, který vás smíří s ČT

Vitalia.cz: Test dětských svačinek: Tyhle ne!

Test dětských svačinek: Tyhle ne!

Vitalia.cz: Tohle jsou nejlepší česká piva podle odborníků

Tohle jsou nejlepší česká piva podle odborníků