Názory k článku Linuxová kancelář a správci databází
-
anonymníVisual FoxPro 9 (VFP) je velmi dobré. Microsoft ji nedomrvil, pouze ji odstavil na vedlejší kolej. FoxPro se jim prostě nehodilo do krámu ... Další vývoj probíhá open source, nicméně do .NET již nikdy předělaná nebude. Vzhledem ke své znalosti, využívám VFP, když rychle potřebuji zpracovat nějaká data, protože je to velmi rychlé - např. import z CSV je jeden příkaz apod. Dříve byl problém s GUI, nicméně v ver. 9 je tvorba GUI velmi příjemná - anchors apod.
Nicméně pro webové programování VFP není, svět je již jinde. Moc nechci MS produkty, tak si nyní hraji s JAVOU. Učím se a přivítám, pokud někdo připojí osobní zkušenosti s DB aplikací v JAVĚ, která má GUI jako tenkého klienta. Zatím zkouším NetBeanS, MySQL, TomCat, Wicket a nejsem moc spokojený. -
minimax (neregistrovaný)Článek o databázích je sice pěkně napsaný, ale to nejdůležitější mi tam schází, a totiž rozsah databázových programů.
Běžné tabulkové programy mají max. asi 10 000 řádek (teď to nevím přesně, můžete mě doplnit, ale moc to není). Access je jen grafickou nadstavbou programu Excel, má tedy stejný rozsah. Totéž asi platí o Kexi. Asi mě upřesníte, ale zhruba tak to je. DBase nebo Fox-ka měly podstatně větší rozsah.
Proč se ptám. Koupil jsem kdysi (nyní je již volně, jako free) prográmek DiskBase. Je to vlastně databáze souborů v počítači, na CD-čkách atd. Zatím jsem nenašel pro tyto účely lepší. Možnost dopisování poznámek, hledání ve všem, tedy i v poznámkách, dělá pro mě tenhle program nenahraditelým (a i to, že mi běhá bez problému ve Wine). Jenže - on čte všechny soubory, které najde, a tak vyrábí databáze statisíců položek. Při exportu a zpracování v jiné obecné databázi se mi import to zhroutí, protože Excel nebo OOffice tolik položek nezpracují. Proto se ptám, zda existuje nějaký program, který by takhle velký balík zpracoval (pochopitelně nejlépe v Linuxu).
Děkuji za rady. -
Rozsahem tedy myslíte maximálně počet položek v jedné tabulce? Ano, u spreadsheetů jsou určité limity, kromě počtu řádků i počet sloupců. U specializovaný databázových strojů (engines) jsou tyto obvykle mnohem vyšší.
Jinak z toho co vím, tak MS Access není jen grafická nadstavba nad Excelem. Má vlastní databázový stroj - jmenuje se Jet (nebo tak nějak podobně, snad ještě s přívlastkem MS, či tak něco). Ten má samozřejmě také určité limity, ale určitě by měly být větší, než u Excelu, snad i řádově.
Jinak pokud Jet nestačí, dělá se to tak, že aplikace v Accessu pak jako backend používá MS SQL server, který ty limity má opět řádově někde jinde.
No ale teď zpátky k Linuxu. V Kexi můžete používat buď SQLite, nebo jako backend můžete použít třeba MySQL. SQLite asi zvládne hodně, ale je fakt, že při větším množství dat s nimi bude asi MySQL pracovat přeci jen trochu efektivněji.
Kolik byste těch řádků tak asi potřeboval? Sám jsem sice netvořil aplikace, ve kterých by byly třeba milióny řádků, ale vím, že i na takové se MySQL běžně používá a problémy s tím nejsou... -
Access a grafickou nadstavbou Excelu? Tak to se trochu proberte.
A jakákoli běžná databáze (i mdb - nativní formát Accessu) statisíce položek zvládne hravě a ještě se bude flákat. Pokud tedy navrhnete slušně strukturu tabulek, indexů, atd..
Jinak Access není jenom databáze, Access je prostředí pro vývoj databázových aplikací a pro správu databází. V Accessu se dá vyvinout velmi pěkná databázová aplikace za několik hodin. Access se může připojit na jakoukoli databázi, nemusí nutně používat nativní mdb formát. -
Alfons (neregistrovaný)To je teda pěkně mimo. Engine Accessu se jmenuje MS Jet. Access je tzv. 4GL nástroj. Aktuální Excel nemá omezení na počet řádků (počet sloupečků si nejsem jistej, ale který db engine nemá omezení na velikost řádku?).
Něco jako DiskBase má aktuálně implementován Mac OS. Na Windowsech to dělá MS :-) nebo Google (+ asi toho bude další milion). -
TomBA (neregistrovaný)V súčasnosti len teoreticky.
Kým nebudú k dispozícii ukážkové aplikácie na úrovni tých čo dodáva MS, kým nebude seriózna dokumentácia, help.
Úroveň prostredia na tvorbu formulárov a tlačových zostáv je neporovnateľná. Tak isto aj možnosti hotových zostáv/formulárov.
Ladenie kódu je neporovnateľné.
Skúsil som OOo Base použiť na jeden menší multiplatformový projekt..... žiaľ zatiaľ nie... možno o 3-5 rokov. -
V práci používáme databázi kontaktů (momentálně cca 500 kontaktů), ke kterým si občas dopisujeme osobní poznámky a potřebujeme v tom všem vyhledávat. Úplně nejdřív to kolega před lety zpracoval v MS Works a teď jsem to překlopili do SugarCRM. Sugar je ovšem značně velká aplikace (asi tak 98% funkcí vůbec nepotřebujeme) a navíc vyhledávání v kontaktech funguje trochu zvláštně.
Pokud bych se pokusil využít např. Kexi nebo Base od OO, bude možné, aby do databáze (na našem serveru) mohli přistupovat současně všichni naši uživatelé a popřípadě každý z nich tam mohl provádět i úpravy?
Dodám, že jsme na to čtyři a každý používáme jiný operační systém (2x WXP, 1x OS a 1x Ubuntu). Na serveru je Mandriva.
Předem díky za případné tipy! -
Alfons (neregistrovaný)V případě Kexi budete muse použít něco jiného než sqlite neb ten je pouze signle user. Ale pokud použijete PostgreSQL či MySQL na serveru,tak na tom budete moci pracovat všichni současně.
Ale ovšem minimálně PostgreSQL NENÍ bezúdržbový RDBMS, takž čas od času je potřeba věnovat čas jeho správě. -
anonymníUdrzet v chodu Oracle je mnohem vice prace nez to same s PGSQL. DB2 je nekde mezi nima. Pracuji se vsema a Oracle je nejhorsi db co se tyce vyzadovaneho bejbysitingu.
Oracle ma ale 2 podstatne vyhody: je draha a zakaznici ji maji radi. Tedy prodejem resenich zalozenych na Oracle vydelate velky balik. -
Alfons (neregistrovaný)Oracle na tom není zas tak zle. Dle mých zkušeností hodně špatného s Oraclem dělají tzv. enterprise aplikace (obvykle jsou to ty Java + Web aplikace). No řekněte - koho z vás by napadlo si při startu aplikace udělat pool 30 otevřených připojení a ty držet ... a držet ... a neuzavírat ani při ukončení aplikace. Tohle je typický problém s každou druhou intranetovou aplikací.
-
Když ji píše dement (a zároveň ji nikdo netestuje), tak ano. Ale v té zmíněné Javě se většinou o databázová spojení stará aplikační server a případně ORM. Držet si už od začátku deset (nebo třeba i třicet) připojení není nic až tak zvláštního – nemusí se čekat, až se připojení otevře (zrovna u Oraclu to chvilku čeká → dost by to zpomalovalo otevření první stránky na webu). -
Alfons (neregistrovaný)Sorry, ale špatně. Proto se přeci implementuje connection pool, abych neměl otevřených 30 připojení aniž cokoliv na db dělám. Pool právě zajišťuje , že je vždy k dispozici X (typicky 1-3) otevřených připojení a pokud se vyčerpají, tak se otevřou další (předem) až do vyčerpání přiděleného počtu connection. Pochopitelně, že pool tyto connection po navrácení recykluje (popř. ukončí a vytvoří nové). Tohle corporátní Java vývojáři nepobrali (teď je to osobní zkušenost, nikoliv nadávání na Javu jako takovou) a vykládají si to jako udělání 30 connection, které neodpojuji ani při restartu aplikace a při startu si prostě naalokuji 30 nových user session. K zblití. A pochopitelně, pokud se jedná o single server (nikoliv farmu), tak po 3-4 restartech aplikace následuje vytuhnut v důsledku nemožnosti vytvoření další connection.
-
LENIN POWER! (neregistrovaný)prestante tu brecet o 30 nepouzitych connectionech v poolu, to se bezne dela protoze tenhle druh zateze ma dost vyrazny spicky a otevreni spojeni do oraclu nejakou dobu trva, tak je potreba mit rezervu. s 1-3 connectionama v poolu nevystacite poradne ani na testovacim stroji.
jinak pro zajimavost db2 umi interni connection pooling transparentni pro aplikace. Mate treba soucasne otevrenych 8000 pripojeni do db zvenku a obsluhujete to 150ti agentama, coz vetsinou staci ponevadz je vetsina dlouhodobe idle u tehle aplikace pracuje soucasne asi 5% uzivatelu. ten pooling se dela aby to setrilo pamet serveru ne aby byly connectiony do db rychlejsi. -
LENIN POWER! (neregistrovaný)No vida, to jsem nevedel. Precetl jsem si k tomu dokumentaci:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc001.htm
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc003.htm#sthref479
Pry to ale nepouzivame (jedeme Oracle10) z duvodu nizsi spolehlivosti. Jinak koukam ze Oracle uz umi session multiplexing jako db2 connect. -
x (neregistrovaný)S tymto prispevkom nemozem suhlasit. Problem nie je 30 otvorenych spojeni na DB. Connection pooling je vyhodny a to predovstkym pri praci s Oracle, pretoze neustale pripajanie a odpajanie na Oracle je neefektivne a ovela pomalsie ako vyuzitie existujuceceho spojenia z poolu. V pripade aplikacneho servera (Java) si mozte Connection pool upravit.
Problem je vsak niekde inde. Problem je v tom, ze Enterprise aplikacie sa snazia byt univerzalne, cize su programovane tak, aby Ste mohli pouzit akukolvek z "mainstream" databaz. A tu je kamen urazu.
Kazda databaza ma svoje specifika a zakonitosti. Univerzalne aplikacie tieto specifika a zakonitosti popieraju. Spominali Ste Oracle, tak uvediem priklad pre Oracle. Pri Oracle ak chcete dosiahnut skalovatelnost aplikacie a minimalizovat waity pri parse faze mali by ste pouzit tzv. viazane (bind) premennne, ktore zapricinia, ze plan pre podobne queries (podobne je mylsene tym, ze zmena dochadza na urovni hodnot v query) sa ulozi v pamati (shared pool) a znovu pouzije. Cize namiesto hard parse sa vykona len soft parse. Ako cloveku dlhodobo administrujucemu Oracle nemusim hovorit, ze hard parse je operacia, ktora vyrazne ovplyvnuje service time, cize dlzku trvania, nez sa dostanete k pozadovanemu vysledku.
Ak je aplikacia pisana aby podporovala viacere druhy DB, napr. MSSQL, PostgreSQL, MySQL a Oracle, tak minmalne kvoli MySQL aplikacia nemoze podporovat viazane premenne. Co ma v pripade Oracleu vazny dopad na performance (zbytocne uzamykanie systemovych prostriedkov atd.) a taktiez to ma aj urcity dopad na bezpecnost (security) aplikacie.
Taktiez velmi zalezi kto a ako dane aplikacie pise. Spominam si na niektore SQL prikazy, ktore su obsiahnute v niektorych enterprise aplikaciach, z ktorych mi bolo takmer doplacu. Vedel by som menovat zodpovedne firmy a aj velkych integratorov, ktori sa nas snazili presvedcit, ze vsetko je OK, ale radsej nebudem. -
LENIN POWER! (neregistrovaný)To je pravda, mne by ovsem zajimalo zda je to pravda nebo ne, nikde ho nejedem.
Pamatuju starej informix nez ho koupila IBM a to byla hrozna sracka. Jelikoz ibm informix porad dale vyviji a pocet zakazniku informixu klesa (neb se jedna o umirajici platformu kterou nepodporuje prakticky zadnej toolchain) tak je logicke ze by potrebovali nove informix zakazniky aby mohli z ceho financovat ten vyvoj. Doporucuji informix pro OLTP aplikace.
Sama IBM zverejnila jakousi roadmap pro informix ze ho bude podporovat do urciteho data +- 5 let a pak se holt uvidi jak budou vypadat sales. Dneska bych do databaze s tak nejistou budoucnosti nesel, zvlast kdyz db2 se dost zlepsila, existuje dost dobra free verze a nativni xml support je cool. -
Berthoud (neregistrovaný)Dobrý den, prosím o radu, jak se nejsnáze naučit práci s SQL a databázemi na uživatelské úrovni ve Windows? Máte někdo zkušenost s databázemi Oracle? Myslíte, že je dobré začít s touto knihou: http://www.eruditus.cz/knihy/luboslav-lacko/oracle-sprava-programovani-a-pouziti-databazoveho-systemu-dvd? Dík za názor.
-
Ar (neregistrovaný)Volba SQL engine zalezi na ucelu pouziti. Pokud zacinate, nejsem si uplne jist, jestli existuje horsi volba, nez Oracle. Je to velice dobry engine na _opravdu_ velke databaze, ale neda Vam vubec nic zadarmo. Na mensi projekty je to strelba taktickou raketou na asfaltove holuby. Velice dobre je Microsoft SQL (v Desktop edici zdarma). Nedodava se k nemu management interface, ale da se stahnout nekolik volnych programu, treba DbaMgr. O MySQL a PostgreSQL muzete taky zcela bez obav sahnout, monumentalni vyhodou je moznost provozovat je na vice platformach.
-
LENIN POWER! (neregistrovaný)v db2 terminologii se rika oracle instanci databaze. db2 instance muze obsahovat nekolik naprosto nezavislych databazi (tedy ne jako to ma pgsql, ktery ma logovani spolecne)
pro zajimavost co se konfiguruje v db2 instanci, jen nezajimave systemove veci:
C:\IBM\SQLLIB\BIN>db2 get dbm cfg
Konfigurace správce databází
Typ uzlu = Databázový server s lokáln
ími a vzdálenými klienty
Verze konfigurace správce databází = 0x0c00
Max. celkový počet otevřených souborů (MAXTOTFILOP) = 16000
Rychlost CPU (ms/instrukce) (CPUSPEED) = 2,361721e-007
Max. počet současně aktivních databází (NUMDB) = 8
Podpora federovaného databázového systému (FEDERATED) = NO
Název transakčního monitoru (TP_MON_NAME) =
Výchozí nákladový účet (DFT_ACCOUNT_STR) =
Cesta pro instalaci sady JDK (JDK_PATH) = C:\IBM\SQLLIB\java\jd
k
Úroveň zachycení diagnostických chyb (DIAGLEVEL) = 3
Úroveň upozornění (NOTIFYLEVEL) = 3
Cesta adresáře diagnostických údajů (DIAGPATH) =
Výchozí přepínače monitoru databází
Fond vyrovnávacích pamětí (DFT_MON_BUFPOOL) = ON
Zámky (DFT_MON_LOCK) = ON
Řazení (DFT_MON_SORT) = ON
Příkazy (DFT_MON_STMT) = ON
Tabulky (DFT_MON_TABLE) = ON
Časové značky (DFT_MON_TIMESTAMP) = ON
Transakce (DFT_MON_UOW) = ON
Sledování narušení instance a databází (HEALTH_MON) = ON
Název skupiny SYSADM (SYSADM_GROUP) =
Název skupiny SYSCTRL (SYSCTRL_GROUP) =
Název skupiny SYSMAINT (SYSMAINT_GROUP) =
Název skupiny SYSMON (SYSMON_GROUP) =
Modul plug-in pro jméno uživatele a heslo klienta (CLNT_PW_PLUGIN) =
Modul plug-in zabezpečení Kerberos (CLNT_KRB_PLUGIN) = IBMkrb5
Modul plug-in skupiny (GROUP_PLUGIN) =
Modul plug-in GSS pro lokální autorizaci (LOCAL_GSSPLUGIN) =
Režim modulu plug-in serveru (SRV_PLUGIN_MODE) = UNFENCED
Seznam modulů plug-in GSS serveru(SRVCON_GSSPLUGIN_LIST)=
Modul plug-in pro jméno uživatele a heslo serveru (SRVCON_PW_PLUGIN) =
Ověřování připojení serveru (SRVCON_AUTH) = NOT_SPECIFIED
Správce klastru (CLUSTER_MGR) =
Ověřování správce databází (AUTHENTICATION) = SERVER
Katalogizace povolena bez oprávnění (CATALOG_NOAUTH) = NO
Ověření všech klientů (TRUST_ALLCLNTS) = YES
Způsob ověření klientů (TRUST_CLNTAUTH) = CLIENT
Vynechání federovaného ověřování (FED_NOAUTH) = NO
Výchozí cesta databáze (DFTDBPATH) = C:
Velikost haldy monitoru databází (4kB) (MON_HEAP_SZ) = 128
Velikost haldy prostředí JVM (4kB) (JAVA_HEAP_SZ) = 2048
Velikost vyrovnávací paměti dozoru (4kB) AUDIT_BUF_SZ) = 0
Velikost sdílené paměti instance (4kB) (INSTANCE_MEMORY) = AUTOMATIC
Výchozí velikost záloh. vyr.paměti (4kB) (BACKBUFSZ) = 1024
Výchozí velikost obnov. vyr.paměti (4kB) (RESTBUFSZ) = 1024
Velikost zásobníku agentů (AGENT_STACK_SZ) = 16
Minimum potvrzené soukromé paměti (4kB) (MIN_PRIV_MEM) = 32
Práh soukromé paměti (4kB) (PRIV_MEM_THRESH) = 20000
Práh haldy pro řazení (4kB) (SHEAPTHRES) = 0
Podpora mezipaměti adresářů (DIR_CACHE) = YES
Velikost haldy pro vrstvu podpory apl.(4kB) (ASLHEAPSZ) = 15
Max. velikost bloku I/O klienta (bajty) (RQRIOBLK) = 32767
Velikost haldy pro dotazy (4kB) (QUERY_HEAP_SZ) = 1000
Vliv obslužných programů na výkon (UTIL_IMPACT_LIM) = 10
Priorita agentů (AGENTPRI) = SYSTEM
Velikost fondu agentů (NUM_POOLAGENTS) = AUTOMATIC
Výchozí počet agentů ve fondu (NUM_INITAGENTS) = 0
Max. počet agentů pro koordinaci (MAX_COORDAGENTS) = AUTOMATIC
Max. počet klientských připojení (MAX_CONNECTIONS) = AUTOMATIC
Udržování chráněného procesu (KEEPFENCED) = YES
Počet chráněných procesů ve fondu (FENCED_POOL) = AUTOMATIC
Výchozí počet chráněných procesů (NUM_INITFENCED) = 0
Doba pro znovuvytvoření indexu (INDEXREC) = RESTART
Název databáze správce transakcí (TM_DATABASE) = 1ST_CONN
Interval pro resynchronizaci (s) (RESYNC_INTERVAL) = 180
Název SPM (SPM_NAME) = DIM23
Velikost žurnálu SPM (SPM_LOG_FILE_SZ) = 256
Omezení počtu agentů SPM (SPM_MAX_RESYNC) = 20
Cesta k žurnálu SPM (SPM_LOG_PATH) =
Název pracovní stanice NetBIOS (NNAME) =
Název služby TCP/IP (SVCENAME) = db2c_DB2
Režim zjišťování (DISCOVER) = SEARCH
Instance serveru zjišťování (DISCOVER_INST) = ENABLE
Max. stupeň paralelizmu pro dotazy (MAX_QUERYDEGREE) = ANY
Povolení paralelizmu v rámci oblasti (INTRA_PARALLEL) = NO
Poč. vnitř. kom. vyrov. pamětí (4kB) (FCM_NUM_BUFFERS) = AUTOMATIC
Počet vnitřních komunikačních kanálů (FCM_NUM_CHANNELS) = AUTOMATIC
Prodleva db2start/db2stop (min) (START_STOP_TIME) = 10
C:\IBM\SQLLIB\BIN> -
Ar (neregistrovaný)Omlouvam se, malicko me zmatl tazatel tim, ze se chtel neco dozvedet o SQL databazich. SQLite neznam, nemohu rici. Access je trochu komplexni pojem. Jde-li tazateli o prostredi, obsahujici vesela kreslitka formularu a sestav s dychavicnym databazovym strojkem nekde v hloubi te binarni smrsti, pak mame viteze. Jak jsem si dovolil uvest v predchozim prispevku - jde o ucel pouziti. Na vyuku prikazu SELECT, INSERT a UPDATE lze pouzit takrka cokoli. V jednoduche podobe je to vsude stejne, slozitejsi dotazy se v T-SQL, PL-SQL, ci jinde budou lisit. Jednoduche veci jsou jednoduche skoro vsude ... tedy krome Oracle. :-D
-
Možná, že Oraclovský CONNECT je příliš jednoduchý. ANSI SQL WITH (CTE) je několikanásobně mocnější - v podstatě CONNECT vlastně skoro nic neumí. CTE je fakt dobrý nápad - http://www.pgsql.cz/index.php/Aktuality#V_8.4_je_ji.C5.BE_implementov.C3.A1na_podpora_rekurzivn.C3.ADch_dotaz.C5.AF a dají se s ním dělat hezké věci, a nijak zvlášť komplikovaný není. -
Palo (neregistrovaný)Odkial sa beriete vy ignoranti. Ja mam radsej open source databazy ako je napr. PostgreSQL a Oracle skutocne neznasam (aj ked ho musim na vyvoj pouzivat). Ale netrufol by som si napisat ze Oracle je sh*t. Bud sa iba neviete vyjadrovat alebo tomu nerozumiete. V kazdom pripade si robite iba hambu.
-
echo zulu (neregistrovaný)prekvapilo, že na týchto žánrovo odlišných stránkach čítam pomerne pozitívne veci na Microsoft Access. Väčšina ľudí, s ktorými som kedy o databázách diskutoval, Access za databázu ani nepovažuje. Navyše sa o ňom vyjadrujú značne pohŕdavým spôsobom.
Pritom výkonovo zvláda záznamy aj státisícov klientov. Overené, odskúšané v praxi a v ostrej prevádzke v rokoch 1997 až 2001, a verím, že súčasné verzie a súčasný hardvér zvládnu ešte viac.
Osobne to vidím tak, že neexistuje ideálny nástroj na každú úlohu, ale nástroj treba vyberať podľa úlohy.
Access určite nie je databázový server, ale dá sa s ním aj napriek tomu spraviť pekná viacpoužívateľská aplikácia, pre nasadenie vo firme a to ľahko, rýchlo a elegantne. Navyše sa to dá aj pomerne používateľským spôsobom, teda aj bez veľkých znalostí programovania. Treba počítať s určitými obmedzeniami, ale dá sa. A to je asi jeho miesto. Je predsa súčasťou Office, nie súčasťou Visual Studia. A trend priblížiť pokročilejšie veci aj nepokročilým používateľom sa predsa netýka len databáz. Dá sa tak začať s prototypom v niečom malom, ten sa dá doplniť a keď to stíha, klient nemá dôvod investovať do veľkého riešenia.
Čo sa OpenOffice týka, bolo by fajn, keby v ňom bola porovnateľná a dotiahnutá alternatíva Accessu. Pokiaľ už nie je. Neviem, neskúsal som. -
Pamatuji MS Access z dob 92-94 a ne, že by se v ní nedaly napsat aplikace, ale padalo to jak šraňky. Výkon Jetu je docela dobrý - MS do Jetu převzal některé technologie z FoxPro, navíc v novějších verzích (a tím si nejsem úplně jistý) používá osekaný engine MS SQL - nicméně asi bych jej nenasazoval pro úlohy se statisícem klientů - tak reálně do 20.
Viděl jsem jak neprogramátoři si v Accessu zbastlili úžasný věci, až mi běžel mráz po zádech :). Je otázkou jestli je to dobře - poměrně rychle se udělá prototyp, ale pak nakonec neprogramátoři narazí, pokud se snaží v A. napsat složitější aplikaci -jde to, ale vyžaduje to dost velkou disciplínu a docela dost zkušeností. -
Palo (neregistrovaný)Ako ekvivalent ku Accesu na Linux by som asi postavil toto: http://www.glom.org
Oracle je ohromna databaza. Je narocna na setup a udrzbu. Na druhej strane nemusite sa bat zverit jej vsetky svoje udaje. Silne neodporucam zaciatocnikom. Na to aby ste pochopili co je tabulka, stlpec, datovy typ, vlozit riadok, urobit nejaky pekny selektik na to nepotrebujete Oracle. Tan vas iba pomyli vsetkymi svojimi moznostami.
A moj nazor na vyvoj frontendu je jasny. Ked frontend tak web. Ak web tak Java. Ak nie web tak tucna Java cize Swing alebo JavaFX.
Ked chcete nejake jednoduche frontendy existuju aj generatory aplikacii. Napriklad:
http://appfuse.org/display/APF/Home
http://jag.sourceforge.net/
Alebo priamo komponenta ktora vam za chodu vytvori 6 druhov interface (Android, Swing, JSF, ...) automaticky alebo s miernou upravou.
http://www.metawidget.org/ -
Alfons (neregistrovaný)Špatně, špatně a ještě jednou špatně.
První otázka pro vývoj frontendu má být - na co a pro koho (pro kolik?). Nikdo nepotřebuje instalovat web server a javu na to, aby si vedl domácí adresář kontaktů.
A jak souvisí web a Java? Asi máte na mysli nějaký framework? Tak schválně - který? (ať se trochu pobavíme :-)) -
Palo (neregistrovaný)Takze je lepsie nainstalovat si OpenOffice alebo MSOffice? Nutit uzivatelov k pouzivaniu niecoho co nechcu? Multiplatformovost?
Najlepsie je web ale preco nie aj tucna aplikacia priamo napojena na bazu. Vsetko v Jave a preco nie aj na adresar kontaktov. Ako vieme aplikaciou na kontakty to nekonci iba zacina. Nepoznam firmu ktora by potrebovala IBA adresar kontaktov. A vdaka WebServru maju dobru sancu ze to nebudu musiet prerabat kazdych 5 rokov. -
Palo (neregistrovaný)So starsou verziou ktora bola oproti tejto nedokonalym pokusom. Toto vyzera velmi dobre, cakam az bude update niektorych balikov aby to isto bez problemov nainstalovat aj do Debianu.
Klientsky OS je dolezity. Glom na inom ako na Linuxe budete rozchadzat tazko (zavislosti na knizniciach ako gtkmm Bakery a podobne.
Nema u vas zmysel pouzit web server z aplikaciou (PHP, Java + MySQL, PostgreSQL)? -
X (neregistrovaný)Neni tu uveden napr. http://tora.sourceforge.net/ ,ale nejlepsi zkusenosti mam s http://www.oracle.com/technology/products/database/sql_developer/index.html .Umi Oracle,MS SQL,MySQL,Sybase a MS Access.
Specializovany pro MySQL a taky vynikajici je http://dev.mysql.com/workbench/ -
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á.
-
To 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 ;) -
anonymníA kto za to moze? Programatori naprogramovali skvely produkt a marketing firmy ho uspesne zlikvidoval vymyslanim velmi cudnych predajnych modelov. Teraz je opensource ale na globalne rozsirenie je uz neskoro. Produkt sice zije ale je dokonale "schovany", je iba pouzity v produktoch, ktore predava S602. Skoda.
-
- Správce aplikací na Technickém úseku
- Senior Product and Business Manager for Securities Services
- Logistics Analyst
- SPECIALISTA/KA IT - OLOMOUC
- IT Business Analyst
- Senior/Medior Java Developer
-
- „Tahák na zdraví“ aneb psychosomatika ve zdravotní prevenci
- Slova a fráze, co vás ve škole nenaučili
- Vzdělávání jako součást života
- Prezentujte v angličtině!
- Uspějte u přijímacího pohovoru a získejte práci snů!
- Jak se efektivně učit online
-
- Správce aplikací na Technickém úseku
- Senior Product and Business Manager for Securities Services
- Automation Engineer for automotive standards
- Logistics Analyst
- JAVA DEVELOPER - J2EE
- SPECIALISTA/KA IT - OLOMOUC
-
- Vzdělávání jako součást života
- Obsahová strategie
- Odvaha vystoupit z komfortní zóny s Tomášem Etzlerem
- Peníze pod kontrolou: průvodce osobními financemi pro každého
- Jak se efektivně učit online
- Pracovní právo SR pro manažery
ČLÁNKY DO MAILU