Hlavní navigace

Názory k článku
Linuxová kancelář a správci databází

Peter Kotrčka aura:100
16. 11. 2008 0:30 Nový

kexi

kexi som uspesne pouzival na domacu databazu pre DX - slusne, rychle, nemozem sa stazovat.
uživatel si přál zůstat v anonymitě
16. 11. 2008 1:56 Nový

FoxPRO

Jasňačka, stará Foxka, to byla pořádná prda ve své době, než to Mrkvosoft zkoupil a totálně domrvil :-(
uživatel si přál zůstat v anonymitě
16. 11. 2008 9:47 Nový

FoxPro

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
minimax (neregistrovaný)
16. 11. 2008 10:07 Nový

dotaz

celé vlákno
Č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.
Marek Turnovec aura:69

Re: dotaz

celé vlákno
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...
Jaromír Vojtaj aura:77
16. 11. 2008 10:57 Nový

Re: dotaz

celé vlákno
Dělal jsem aplikaci, kde bylo cca 5 mil. řádků v jedné tabulce a MySQL si s tím poradil naprosto v pohodě a docela rychle
VRtulnikk
VRtulnikk (neregistrovaný)
16. 11. 2008 11:57 Nový

Re: dotaz

celé vlákno
Nevím, jak v Linuxu, ale u MS Excelu jdou tyto limity bez problému obejít úpravou šablony...
Miloslav Ponkrác aura:67
16. 11. 2008 12:37 Nový

Re: dotaz

celé vlákno
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
Alfons (neregistrovaný)
16. 11. 2008 13:15 Nový

Re: dotaz

celé vlákno
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
TomBA (neregistrovaný)
16. 11. 2008 11:08 Nový

OOo Base ako alternatíva k MS Access

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áclav Čermák aura:77

Malá databáze

celé vlákno
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
Alfons (neregistrovaný)
16. 11. 2008 13:20 Nový

Re: Malá databáze

celé vlákno
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ě.
uživatel si přál zůstat v anonymitě
16. 11. 2008 17:25 Nový

Re: Malá databáze

celé vlákno
postgresql je prakticky bezudrzbova db, autovacuum to jisti pokud nedojde misto na disku.
Alfons
Alfons (neregistrovaný)
17. 11. 2008 0:27 Nový

Re: Malá databáze

celé vlákno
Není. Správcuji už 10 let Oracle, MS SQL, PostgreSQL, a kdysi i Sybase, velké (desítky gigabajtů) databáze. Ani jeden z těchto RDBMS není bezúdržbový (teda počítám s tím, že s emi na něj připojují uživatelé a tudíž neběží nachlucho).
uživatel si přál zůstat v anonymitě
17. 11. 2008 13:03 Nový

Re: Malá databáze

celé vlákno
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
Alfons (neregistrovaný)
17. 11. 2008 14:13 Nový

Re: Malá databáze

celé vlákno
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í.
Franta Kučera aura:80
17. 11. 2008 15:30 Nový

Re: Malá databáze

celé vlákno
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
Alfons (neregistrovaný)
17. 11. 2008 23:21 Nový

Re: Malá databáze

celé vlákno
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!
LENIN POWER! (neregistrovaný)
17. 11. 2008 23:38 Nový

Re: Malá databáze

celé vlákno
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.
x
x (neregistrovaný)
18. 11. 2008 0:48 Nový

Re: Malá databáze

celé vlákno
No nieco podobne ma aj Oracle, vola sa to shared server architecture. Mal to tusim uz od 8i (vtedy sa to volalo MTS cize multithreaded server). V tomto pripade sa ti agenti volaju shared server procesy, ktore si vyberaju dotazy z queue.
LENIN POWER!
LENIN POWER! (neregistrovaný)
18. 11. 2008 11:35 Nový

Re: Malá databáze

celé vlákno
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
x (neregistrovaný)
18. 11. 2008 23:50 Nový

Re: Malá databáze

celé vlákno
Shared server sa hodi na nieco a na nieco nie. Ale, kto tvrdi, ze nie je spolahlivy, tak siri FUD (resp. zavadza). U nas to pouzivame cca 6 rokov (od 9i) a nezaznamenali sme nejaky problem s nespolahlivosotu a to tato databaza je hodne vyuzita.
x
x (neregistrovaný)
17. 11. 2008 23:40 Nový

Re: Malá databáze

celé vlákno
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.
me
me (neregistrovaný)
17. 11. 2008 16:21 Nový

Re: Malá databáze

celé vlákno
Bezudrzbovy by mel byt INFORMIX, tak jej aspon prezentuje IBM. Informix Dynamic Server.
LENIN POWER!
LENIN POWER! (neregistrovaný)
17. 11. 2008 18:49 Nový

informix

celé vlákno
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.
x
x (neregistrovaný)
17. 11. 2008 22:23 Nový

Re: Malá databáze

celé vlákno
Absolutne suhlasim s kolegom. Ziadny z velkych RDBMS nie je bez udrzbovy.
Miloslav Ponkrác aura:67
16. 11. 2008 12:40 Nový

Neexistuje dobrá alternativa Accessu

celé vlákno
Přes optimistická prohlášení v článku neexistuje srovnatelně dobrá alternativa Accessu. Do toho je ještě hodně daleko.
Alfons
Alfons (neregistrovaný)
16. 11. 2008 13:23 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
Ani to Kexi? Nepůsobí to na mě jako amatérština. A scriptování v Pythonu či v Ruby ... to by mohlo být mnohem dále než VBA.
بطر&#15
بطر&#15 (neregistrovaný)
17. 11. 2008 7:13 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
A k čemu je takový nesmysl?
JS
JS (neregistrovaný)
17. 11. 2008 11:33 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
Domaci kartoteka? Ja nevim, jestli existuji OSS alternativy, poucte me.
uživatel si přál zůstat v anonymitě
17. 11. 2008 12:38 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
To zni pomalu jako domaci ucetnictvi nebo jeste lepe domaci sklad, domaci kniha jizd pripadne domaci HA cluster :-)
bodlinka (kolemctouci)
bodlinka (kolemctouci) (neregistrovaný)
17. 11. 2008 23:16 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
Co mate proti domacemu HA clusteru?
Nevravim, ze ho ma doma kazdy druhy clovek, ale par sa ich isto najde.
(tym nemam na mysli tie pod vmware ci virtualboxom)
uživatel si přál zůstat v anonymitě
17. 11. 2008 19:45 Nový

Re: Neexistuje dobrá alternativa Accessu

celé vlákno
Na Windows alternatíva existuje, volá sa 602SQL, jej starsia verzia 8.1 dokaze vsetko co bezny clovek potrebuje a uz niekolko mesiacov je free. Zial Software602 sa zameral na novu verziu (aktualne 11), kde niektore funkcie vypustil. Patche ale vydava aj na starsiu verziu.
Berthoud
Berthoud (neregistrovaný)
16. 11. 2008 14:14 Nový

Prosím o radu.

celé vlákno
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.
uživatel si přál zůstat v anonymitě
16. 11. 2008 17:03 Nový

Re: Prosím o radu.

celé vlákno
Ale jo, kupte si knizku a stahnete ten free Oracle a muzete zacit zkouset. Musim ale upozornit ze Oracle je velmi komplexni (slozitejsi nez je nutne) asi by mssql bylo pro zacatek lepsi a v CR je popularnejsi.
Ar
Ar (neregistrovaný)
16. 11. 2008 21:03 Nový

Re: Prosím o radu.

celé vlákno
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.
Alfons
Alfons (neregistrovaný)
17. 11. 2008 0:36 Nový

Re: Prosím o radu.

celé vlákno
Ne, není. Pokud začínáte s databázemi, tak zapomeňte pro první semestr (:-)) na Oracle a vemte si něco jednoduchého jako je právě Access nebo sqlite. Až se zorientujete v principech, tak se můžete vrhnout na enterprise enginy jako je právě Oracle i PostgreSQL nebo MS SQL.
uživatel si přál zůstat v anonymitě
17. 11. 2008 0:49 Nový

Re: Prosím o radu.

celé vlákno
Nas ve skole ucili databaze na Oraclu, bezelo to na OpenVMS a nijak strasne mi to neprislo.
Lojza
Lojza (neregistrovaný)
17. 11. 2008 1:00 Nový

Re: Prosím o radu.

celé vlákno
No joi, protože jste byli ušetřeni instalace a správy Oracle. :-)
Samotné SQL je pro začátečníky všude stejné. Rozdíly přijdou s prvním outer joinem.
uživatel si přál zůstat v anonymitě
17. 11. 2008 11:29 Nový

Re: Prosím o radu.

celé vlákno
SQL oraclu bylo s postgresql nekompatibilni uz od prvni hodiny, ale neprislo mi to jako problem. Pokud Vam nevadi, ze budete mit databazove spatne prenositelne aplikace, tak je to jedno.
Alfons
Alfons (neregistrovaný)
17. 11. 2008 14:16 Nový

Re: Prosím o radu.

celé vlákno
Zrovna PostgreSQL, resp. pg/sql poměrně masivně a beze studu kopíruje pl/sql. takže maximálně se vám trošku pozmění syntax, ale nebudete muset překopávat celou akrchitekturu DALu vaší aplikace (což se vám stane v okamžiku portace na MS SQL/Sybase či MySQL).
LENIN POWER!
LENIN POWER! (neregistrovaný)
17. 11. 2008 19:09 Nový

Re: Prosím o radu.

celé vlákno
row version control je uplne jine v Oracle vs Pgsql, pokud jenom prepisete u stored procedur syntax budete mit v aplikaci races.
LENIN POWER!
LENIN POWER! (neregistrovaný)
17. 11. 2008 22:38 Nový

Re: Prosím o radu.

celé vlákno
instalace oraclu we windows je klikaci a spravu netreba pro vyukove ucely delat, proste kdyz to pohnojite zrusite databazi a vytvorite si ji znova.
Alfons
Alfons (neregistrovaný)
17. 11. 2008 23:28 Nový

Re: Prosím o radu.

celé vlákno
No, já myslím, že zcela za vše mluví to, že místo o instanci či schematu mluvíte o databázi. :-))
LENIN POWER!
LENIN POWER! (neregistrovaný)
20. 11. 2008 1:42 Nový

Re: Prosím o radu.

celé vlákno
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
Ar (neregistrovaný)
17. 11. 2008 1:53 Nový

Re: Prosím o radu.

celé vlákno
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
Lojza
Lojza (neregistrovaný)
17. 11. 2008 8:10 Nový

Re: Prosím o radu.

celé vlákno
Tak si na MS SQL (2005 a vyšší) zkuste napsat hierarchické query a pochopíte krásu, jednoduchost a ladnost Oraclovského CONNECT BY.
honzak
honzak (neregistrovaný)
17. 11. 2008 11:53 Nový

Re: Prosím o radu.

celé vlákno
to mohu potvrdit, moje sestrenice je sekretarka a uz u prijimaciho rozhovoru se ji ptali, jestli zvlada hierarchicke query, neb to je u nich normalni, ostatne jako v kazdem jinem beznem zamestnani.

Ctenari prosim vezmou na vedomi, ze Lojza je db-guru....
Alfons
Alfons (neregistrovaný)
17. 11. 2008 14:09 Nový

Re: Prosím o radu.

celé vlákno
Za to vy evidentně neumíte sledovat text v diskuzi (jak symbolické - je ve stromové struktuře), takže vám by nepomohl ani MS Access s propojeným Excelem.
Pavel Stěhule aura:89
17. 11. 2008 15:08 Nový

Re: Prosím o radu.

celé vlákno
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í.
speedy
speedy (neregistrovaný)
16. 11. 2008 20:08 Nový

ORACLE

celé vlákno
Oracle je sh*t, pokud jsi někdy psal pořádný databázový coldware
Palo
Palo (neregistrovaný)
16. 11. 2008 23:14 Nový

Re: ORACLE

celé vlákno
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
echo zulu (neregistrovaný)
16. 11. 2008 22:52 Nový

Veľmi ma

celé vlákno
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.
Pavel Stěhule aura:89
17. 11. 2008 6:40 Nový

Re: Veľmi ma

celé vlákno
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
Palo (neregistrovaný)
16. 11. 2008 23:06 Nový

Este jeden

celé vlákno
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
Alfons (neregistrovaný)
17. 11. 2008 0:33 Nový

Re: Este jeden

celé vlákno
Š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
Palo (neregistrovaný)
17. 11. 2008 23:09 Nový

Re: Este jeden

celé vlákno
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.
Václav Čermák aura:77

Re: Este jeden

celé vlákno
Máte s Glomem nějaké praktické zkušenosti? To by mohlo být řešení pro malou databázi - pokud do ní může přistupovat více uživatelů najednou a zároveň i provádět změny. Předpokládám, že operační systém přistupujícího uživatele není rozhodující. Děkuji!
Palo
Palo (neregistrovaný)
17. 11. 2008 23:24 Nový

Re: Este jeden

celé vlákno
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
X (neregistrovaný)
17. 11. 2008 9:20 Nový

RE: Linuxová kancelář a správci databází

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/
Franta Kučera aura:80
17. 11. 2008 11:25 Nový

SQL pro normální uživatele

celé vlákno
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
honzak (neregistrovaný)
17. 11. 2008 11:44 Nový

Re: SQL pro normální uživatele

celé vlákno
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.
Franta Kučera aura:80
17. 11. 2008 14:08 Nový

Re: SQL pro normální uživatele

celé vlákno

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.

Pavel Stěhule aura:89
17. 11. 2008 15:01 Nový

Re: SQL pro normální uživatele

celé vlákno
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.
Franta Kučera aura:80
17. 11. 2008 15:39 Nový

Re: SQL pro normální uživatele

celé vlákno
"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í!
Pavel Stěhule aura:89
17. 11. 2008 16:02 Nový

Re: SQL pro normální uživatele

celé vlákno
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
honzak (neregistrovaný)
17. 11. 2008 17:03 Nový

Re: SQL pro normální uživatele

celé vlákno
...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
Alfons (neregistrovaný)
17. 11. 2008 14:22 Nový

Re: SQL pro normální uživatele

celé vlákno
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!
Pavel Stěhule aura:89
17. 11. 2008 15:23 Nový

Re: SQL pro normální uživatele

celé vlákno
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.
honzak
honzak (neregistrovaný)
17. 11. 2008 17:09 Nový

Re: SQL pro normální uživatele

celé vlákno
...místo klávesy DEL použil bílé písmo na bílém pozadí ...

priznejte se, to jste si vymyslel ..

(OT) To spis uverim, ze je ODS pravicova strana ....
uživatel si přál zůstat v anonymitě
17. 11. 2008 18:41 Nový

Re: SQL pro normální uživatele

celé vlákno
Taky jsem neco podobneho uz videl, nekdy se az divim, co jsou BFU schopne vymyslet.
Veterán
Veterán (neregistrovaný)
17. 11. 2008 19:31 Nový

Re: SQL pro normální uživatele

celé vlákno
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.
Pavel Stěhule aura:89
17. 11. 2008 20:50 Nový

Re: SQL pro normální uživatele

celé vlákno
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
Veterán (neregistrovaný)
17. 11. 2008 21:40 Nový

Re: SQL pro normální uživatele

celé vlákno
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 Stěhule aura:89
18. 11. 2008 5:27 Nový

Re: SQL pro normální uživatele

celé vlákno
ju, profesionální deformace
Pavel Stěhule aura:89
17. 11. 2008 20:01 Nový

Re: SQL pro normální uživatele

celé vlákno
Jednou za čas člověka život překvapí :). Fakt se to stalo.
Pavel Tišnovský aura:98
19. 11. 2008 21:42 Nový

Re: SQL pro normální uživatele

celé vlákno
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
Alfons (neregistrovaný)
17. 11. 2008 23:33 Nový

Re: SQL pro normální uživatele

celé vlákno
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". :-)
Pavel Stěhule aura:89
18. 11. 2008 5:34 Nový

Re: SQL pro normální uživatele

celé vlákno
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
Lojza (neregistrovaný)
18. 11. 2008 9:47 Nový

Re: SQL pro normální uživatele

celé vlákno
To je chování, které se dá nastavit. Z historických důvodů je Oracle nastaven, aby ukládal empty string jako null.
Franta Kučera aura:80
17. 11. 2008 15:44 Nový

Re: SQL pro normální uživatele

celé vlákno
"desítky tisíc řádek; spousta maker a vytváření metadat."

Takové peklo bych nechtěl zažít :-) Zlaté relační databáze, kde většinu věcí udělá deklarativně a na ten zbytek si napíšeš pár procedur.
Alfons
Alfons (neregistrovaný)
17. 11. 2008 23:36 Nový

Re: SQL pro normální uživatele

celé vlákno
Jistě - jenže jak říkám - analytik to splácal za 14 dní a 7 let na tom jeli (teda jedou na tom stále).
Alfons
Alfons (neregistrovaný)
17. 11. 2008 23:39 Nový

Re: SQL pro normální uživatele

celé vlákno
A teď si představte mašinu (teda rozhodně farmu), která obslouží asi 500 uživatelů a kolik by stál projekt na zhotovení takové aplikace (+ případné licence).

A to je celej fígl úspěchu Excelu.
Franta Kučera aura:80
18. 11. 2008 8:13 Nový

Re: SQL pro normální uživatele

celé vlákno
A ten Excelovský sešit obslouží 500 uživatelů? To bude sešit na sdíleném disku? :-)
Lojza
Lojza (neregistrovaný)
18. 11. 2008 9:49 Nový

Re: SQL pro normální uživatele

celé vlákno
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
Papouch (neregistrovaný)
17. 11. 2008 15:55 Nový

Re: SQL pro normální uživatele

celé vlákno
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 ;)
me
me (neregistrovaný)
18. 11. 2008 11:20 Nový

602SQL

celé vlákno
Na 602SQL se uplne zapomnelo... ;-)

http://sql602.sourceforge.net/
uživatel si přál zůstat v anonymitě
19. 11. 2008 20:34 Nový

Re: 602SQL

celé vlákno
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.
Zasílat nově přidané příspěvky e-mailem