Vlákno názorů k článku Linuxová kancelář a správci databází od Franta Kučera - Ahoj. Myslíte, že je reálné, aby někde ve...
-
Ahoj. Myslíte, že je reálné, aby někde ve firmě byl SQL server (třeba PostgreSQL) a obyčejní uživatelé (neajťáci) by se k němu připojovali nějakým GUI klientem (např. pgAdmin III). A místo aby si zakládali nějaké přitroublé excely, tak by si prostě vytvářeli tabulky ve svém schématu na serveru? Mohli by vytvářet různé SQL dotazy, používat agregační a jiné funkce atd. Časem by se přidal nějaký reportovací nástroj, nebo by se připojovali něčím, co kreslí i grafy… U nás umí SQL i analytici a část lidí z byznysu, takže mi to až tak nereálné nepřijde, ale zajímalo by mě, jak to vidí ostatní? -
honzak (neregistrovaný)to je zajimavy dotaz a mozna i tak trochu zasadni, protoze se tyka filosofie toho, jakym smerem se chceme v budoucnu ubirat. To co pisete bylo snem v zacatcich vyvoje sql jako dotazovaciho jazyka (vubec se nemyslelo na nejakou podporu v programovacim prostredi) a moje analyza je, ze tento sen se neuskutecnil!
Mam radu zkusenosti s mnozstvim zakazniku v ruznych firmach. Je treba to trochu rozdelit:
1. mala soukroma firma -> sql absolutne nenasaditelne
2. velka firma -> tam se to dela, ale tak, ze se vezme access a za jeji pomoci se sesmoli sql-dotaz. V komlikovanem pripade to jeden schopnejsi v oddeleni udela pro kolegy. Vysledek jde do excelu, protoze to 'umi' kazdy. Nevyhodou je, ze 1 x za tyden nekdo spusti dotaz, ktery zablokuje provoz serveru na nekolik hodin a vola se administrace. Pan Stehule namitne, ze to je chyba administratora, ale pan Stehule nemuze delat administratora ve vsech firmach sveta soucasne.
3. Urad -> tam je to mozne, protoze na case nezalezi a samovzdelavani na pracovisti v pracovni dobe je porad lepsi nez se kopat patama do zadku.
4. Vseobecne je situace v postkomunistickych zemich lepsi (z hlediska nasazeni sql), protoze zde jeste pretrvava to socialisticke nimrani se v problemech a ve vedeni jsou i nadale zoufalci, kteri by na zapade mohli ridit akorat vratnici. -
SQL dává uživatelů možnost být kreativní, vymýšlet nová řešení, kdežto když jsou ty dotazy zadrátované* v aplikaci, dělají to pořád stejně, jako opice, a nezbývá než se spoléhat na upgrady aplikace (tedy že kreativní bude autor softwaru, nikoli uživatel) – ty ale musí být dost časté, aby se situace posouvala dopředu.
Samozřejmě taky záleží na pozici a schopnostech toho uživatele – někteří jsou schopni vymyslet něco přínosného a jiní tak maximálně zahltí databázi nesmyslnými dotazy.
*) možná je rozumným kompromisem QBE.
-
p. Stěhule pouze podotkne, že je v takových případech je docela dobrý nápad nastavit limit na dobu provádění dotazu, ostatně to je dobrý nápad vždy a pěti minutami se nic nezkazí.
Z posledního (a prvního školení SQL pro roota) mám poměrně zajímavou zkušenost - jsou firmy, kde jsou běžní zaměstnanci nuceni sestavit nějaký ten SQL dotaz, a občas se jim to i daří :). Ad hoc SQL dotazy mohou firmě řešit čas a peníze - peníze ani ne - hodně firem platí paušál za servis, a v něm mají určitý počet hodin podpory zdarma - menší reporty se do toho vejdou. Důležitější je čas - programátor málo kdy chápe, co po něm účetní chce, takže než se domluví trvá to měsíc, dva. U jednodušších reportů je to naprosto neefektivní.
Jinak s Vaším dělením můžu souhlasit - ve větších firmách (a zvlášť v těch fakt velkých) mají vyčleněno (proškoleno) pár (někdy i desítky zaměstnanců), kteří jsou schopní sestavit report. Reálně ovšem není problém naučit se SQL - to se fakt dá zvládnout relativně snadno. Ale jsou tu desítky IS, které mají tak divoce navrženou datovou strukturu, že i s dobrou znalostí SQL docela plavete. Pokud chci pustit neprogramátory k datům, tak musí být databáze přehledně navržena.
Tady vidím dost velký paradox. Jako běžnou znalost se po zaměstnancích vyžaduje tvorba reportů v Excelu, přičemž při znalosti SQL je generování reportu třeba v Accessu mnohem jednoduší. Jenomže na to už je potřeba SQL, které má kolem sebe auru nepochopitelnosti, nenaučitelnosti. -
"SQL, které má kolem sebe auru nepochopitelnosti, nenaučitelnosti."
A přitom SQL je strašně krásný a jednoduchý jazyk. První jednoduché dotazy může psát člověk už po pár minutách, stačí si uvědomit, jaké sloupečky z jaké tabulky chce vidět (nebo aspoň z jaké tabulky → *), brzo se naučí i podmínky, aspoň ty triviální = < > a zbytek přijde časem.
Myslím, že je škoda, že k tomu má hodně lidí odpor a bojí* se toho – přitom naučit se základy SQL je jednodušší než si zapamatovat milion dialogů v Excelu. IMHO je tenhle jazyk použitelný i pro nepočítačově založené lidi. Ale jak píšeš, záleží dost na přehlednosti datového modelu (někdy aby se v tom prase vyznalo, to pak nepomůže ani pokročilá znalost SQL).
*) ne že by to nezvládli, nebo dělali chyby, ale oni to ani nezkusí! -
Tady jsem docela optimista - v podstatě už je dobojováno - SQL smetlo ISAM. Každý programátor by měl umět základy SQL (na FoxPro a starší už pamatuje jen pár veteránů), SQL se vyučuje běžně na vysokých školách, takže reputace SQL se bude jen zlepšovat. Tím zas nemíním, že SQL se bude nějak rapidně prosazovat mezi ne-it uživateli. Vždy bude jen minimum ne-it uživatelů, ne-it firem, kterým se to vyplatí. Ale už se nikdo SQL nebude bát.
-
honzak (neregistrovaný)...v podstatě už je dobojováno ...
to firmy jako M$ a ostatni nedopusti. I dalsi generace musi dostat neco noveho, co tu jeste nebylo, co zmeni totalne IT svet, kdy se budou aplikace psat takrikajic samy, vsechno bude mnohem lepsi, jistejsi, bezpecnejsi, ruzovejsi, vonavjejsi - proste musi prijit zmena paradigma - z ceho by napr. zily skolici instituce? Nove frameworky, Studia apod. ktere umozni novym absolventum byt na tom 3 roky lepe nez ti, co vysli 5 let pred nimi. A u databazi ocekavam zrovna to same. Do 3 let ocekavam slogany typu data-warehouse do kazdeho ucetnictvi. -
Alfons (neregistrovaný)Možná na jednoduché věci by to fungovalo. Ale viděl jsem rozpočet splečnosti, jejíž roční obrat se točil ve stovkách milionů Euro udělaný v několika Excelovských souborech.
Obsahovalo to desítky listů a na každém z nich desítky tisíc řádek; spousta maker a vytváření metadat. Výsledkem ve finále byla pivot tabulka. Data se sbírala v rámci hierarchie společnosti agregovaně s tím, že každý šéf vždy sloučil data od svých podřízených do jednoho sešitu. Docela masakr, ale fungovalo to (v době, kdy jsem k tomu přišl už 7 let) a hlavně - dal to dohromady jeden analytik asi za 14 dní (programátor na to ani nesáhnul)!!! V tom je ta síla Excelu! -
Už jste někdy měl chuť rozmlátit klávesnici o monitor? Já jednou. Tehdy pro Motorolu jsem napsal generátor reportů z Excelovských tabulek - psalo se to poměrně dobře, až na to, že při předávání jsme šest, osm hodin hledali chybu, jelikož nám neseděly výsledné tabulky. V deset hodin večer bych už věřil i na zázraky - pak jsme přišli na to, že někdo pro mazání hodnot místo klávesy DEL použil bílé písmo na bílém pozadí. To je něco, co se Vám v db nikdy nestane.
Další příklad proti zneužívání Excelu. Na vojně, tam kde jsem sloužil, si jeden kapitán udělal evidenci spotřeby pohonných hmot a olejů v Excelu. Co měsíc, to nový sheet.Co rok, to nový soubor. Po třech letech přepočítání trvalo kolem 10-15 minut. Po převedení dat do Accessu trvalo sestavení reportu 10 sekund. Věci v Excelu fungují, ale soubor musí být přesně na C v daném adresáři, nesmí být zamčen, a občas se při ukládání rozbije. Databáze jsou mnohem robustnější. Excel je fajn jako koncové zařízení, ale data, by pro Pána Boha, měla být zásadně udržovaná v databázi. -
Veterán (neregistrovaný)Je to od vás trošku protimluv. Jednou stranou se na těchto stránkách požaduje, aby BFU dokázal pracovat s konfiguračnímu soubory, nebyl jen klikač atd. a na druhé straně, když vytvoří něco, co splňuje jeho požadavky a prokáže tedy vlastní iniciativu, všichni se podivují nad tím, co je schopen napáchat.
Já třeba znám i sekretářky píšící si aplikace v VBA. Když se na to podívám vidím, že jsou programátorsky humpolácké a šly by přepsat a tím i značně zrychlit. Ale ony plní jejich požadavky a když vezmu do úvahy cenu programátora, firma by to nikdy nezadala.
Jedná se tedy o další část cesty, jak umožnit BFU lépe pracovat s počítačem a nemuset se stávat odborníkem na něco jiného, než je jeho obor. A možná to v budoucnu způsobí to, že vymizí mizerní programátoři (kódovači) a zůstane špička tvořící rozsáhlé projekty. -
Nechtěl jsem nikoho urazit - vím, že dost lidí si napsalo sw, který používá, ze kterého měli při psaní radost, že jim to funguje, a ono jim to funguje. Člověku to občas ujede. Programováním jsem se živil posledních 15 let a určitě všechny moje aplikace by se daly přepsat a napsat lépe - a to jsem ještě měl kliku na hodně dobré učitele na ČVUT, kteří mi hodně věcí vysvětlili. Také dnešní technologie jsou úplně o něčem jiném. To, co kritizuji, je skutečnost, že sw se používá příliš jednoduše, špatně, všelijak se ohýbá - zažil jsem firmy, kde se faktury řešily v t602, slyšel jsem o lidech, kteří psali dopisy v Excelu, ... nejpopulárnější formát pro přenos číselníků v ČR je xls, který je asi tím nejhorším, atd - aplikace, které vznikly jako nouzovka (prototyp) se pak používají jako běžné (profi) aplikace. Ale taková je asi realita a nemá se kvůli tomu cenu vzrušovat.
-
Veterán (neregistrovaný)Faktury v T602 pamatuji. Jenže tenkrát malé firmy koupily počítač a T602 jako lepší psací stroj. O tabulkovém procesoru ani nevěděly a také stál dost peněz. Takže to řešily takto. Lidé si poradí úměrně svým schopnostem a finančním možnostem. Je to prostě vždy stejné. když budu potřebovat náhodou zatlouct hřebík v přírodě, klidně použiji kámen. Normálně mám kladivo, ale když jich budou tisíce, použiji pneumatickou pistoli. A my, lidé kolem počítačů, se na to díváme právě z pohledu oné pistole. je nejlepší, ale na občasné použití poněkud drahá.
-
Pavel TišnovskýZlatý podporovatelTo já zase zažil "profesionální" informační systém, který v některých tabulkách (Oracle) obsahoval číselná ID (PK) uložená jako varchar(5), protože vedoucí vývojového týmu potřeboval mít ta čísla na formulářích zprava vyplněná nulami (druhá věc je, proč vůbec ID potřeboval zobrazit, ale to je na delší povídání). Donutil tedy vývojáře, aby např. ID=1 do databáze uložili jako "00001" atd., nikomu vůbec nedošel rozdíl mezi interním uložením čísla a způsobem jeho zobrazení. Takže mě potom datumy uložené jako varchar(10), tj. "01-10-2008" už v této aplikaci vůbec nepřekvapily, stejně jako dotazy typu:
select * from stp where nvl(type, '')=''
místo lidského:
select * from stp where type is null
(vím, nejsou to ekvivalentní dotazy, ale v dané DB struktuře byly, type bylo buď neprázdný řetězec nebo null). -
Alfons (neregistrovaný)White forecolor místo DEL? To je přeci od toho uživatele geniální. Úplně to vidím :-))))
Databáze mají zase jiný problém. Jsou uživatelé, kterým nevysvětlíte rozdíl mezi null, empty string, space a tabulátorem (či jiným white space). Pro ně je to prostě jenom "žádná hodnota". :-) -
Se spreadsheetem totiž může dělat každý, bez jakéhokoliv proškolení - ten nápad je fakt geniální. Kdežto u databází se alespoň musí navrhnout struktura tabulek - a tam už se dají navázat podmínky. Ale na druhou stranu, třeba u MySQL constrainty zvysoka ignorovali, a lidem, kteří používali - používají MySQL to vůbec, ale vůbec nevadilo - těm, co to vadilo, přešli na PostgreSQL nebo Firebird.
Je databáze, kde není rozdíl mezi NULL a empty stringem - ta db se jmenuje Oracle. -
Lojza (neregistrovaný)Další, kdo neumí sledovat diskoz ve stromové struktuře. :-)
ne, ten Excelovský soubor se emailově distribuuje a následně skrze organizační strukturu jsou vždy údaje z jednotlivých filů agregovány příslušným vedoucím/managerem, takže se ve finále na vrcholku sejde jeden velký Excel file. -
Papouch (neregistrovaný)u jednoduchych databazi je to naprosto realne
priklad ze zivota - webova aplikace sbira a zpracovava nejaka data od stovek uzivatelu, ktera bylo potreba ad hoc vyhodnotit
namisto napsani reportovaciho modulu stacilo ukazat (kucharka), jak se do Excelu pridava datovy zdroj na postgres db (v nejjednodussim pripade co tabulka v db to sheet)
dal uz jsem se jen divil, co s tim Excelem vsechno umeji provadet ;)
