vyvojove prostredi pro informacni systemy (diskuse)

[JiK]

SAP?

[Kyosuke]

Hodlám úkol vytvoření pracovního IS atakovat kombinací Tcl/Tk a Lispu (TCP backend). Lepší nástroje jsem nenašel, obzvlášť pro deklarativní popis databáze (která se bude dost živelně vyvíjet – budu rád, když se migrace odbudou samy, což CLOS dělá, na rozdíl od hromady podřadnějších objektových systémů... ) a generování GUI napůl dynamicky a přitom do čitelného kódu. Některé operace budou trošku nestandardní (customized fulltext v texové databázi), relační databáze se mi do toho proto moc tahat nechce, objekty tohle řeší líp. Prevalence by ta data měla zvládnout, tím se vyřeší tři čtvrtě problémů.

Klient desktopový, zabalený do Starkitu, který si bude ze serveru tahat taky generované GUI (aktualizace klienta: řeší se samy. ). Řekněme, že Tk pro mé účely má jisté výhody (oproti jiným řešením) a na cílové platformě, která nebude unixová, nemusím tolik řešit vzhled, na jehož vylepšení se v unixovém Tk teprve pracuje. Jsem holt minimalista. Jestli klient bude mít mega a půl a server čtyři mega (oboje celkem), bude to hodně a přitom to bude kompletní.

Je pravda, že překladatelská knowledge base nemá s účetnictvím moc společného, ale pro mně je to pracovní IS.

[springer]

uz jste delal rychlostni testy pro ten client. Napr kdyz si natahnete ze servru popis nejake masky, ktera ma 500 elementu. Tyto elementy se musi vytvorit, vsem nastavit vlastnosti, vytvorit conectory pro eventy, ulozit nekam ty funkcni fragmenty pro reakce na ty eventy apod. Ja jsem to zkousel pod Qt a dostal jsem se na 3 sekundy. Rychlejsi frameworky to dokazou tak za 0.5 sekundy - coz jde. U tech interpretru bych mel trochu strach.

To s tou databazi jsem uprime receno nepochopil, ale to ze se vam nechce pouzivat relacni je chvalyhodne. (asi trochu neprakticke). Ale jak jsem tomu porozumnel, tak to bude prostredi pouze pro vas a ne pro sirsi verejnost - nebo jak?

[Kyosuke]

Nevím, co je praktického na psaní algoritmů v SQL nebo tvorbě šílených pomocných tabulek, abych mohl psát algoritmy pomocí joinů a podobně. Jak říkám, nebude to účetnictví s čísly. Radši bych to měl pohromadě, psát SQL do kódu mi přijde asi tak elegantní, jako psát PHP kód do HTML stránek. (SQL nevzniklo jako programátorské API, i když si to dnes bůhvíproč spousta lidí myslí.)

A netuším, proč bych se měl bát nízké rychlosti. Tahle technologie vznikla v první polovině 90. let přesně za tímhle účelem a evidentně funguje, lidi v tom takové aplikace dělají. Kromě toho, pokud spuštění aplikace bude trvat pár sekund, tak se snad nic neděje. Spousta aplikací se spouští pár sekund. Co přesně máte na mysli tou "maskou"? Měla by to být aplikace pro cca. 10-15 lidí s důrazem na retrieval textových dat.

[springer]

k tomu SQL - absolutni souhlas, jedina nevyhoda (a sam ji uvadite) je to, ze si "spousta lidi" mysli, ze ta SQL je od Boha dana a ja jsem musel bohuzel zjistit, ze kdyz clovek hlasa neco jineho, tak je na tom podobne jak Kopernik (ten radeji to, ze je Zeme kulata nechal uverejnit az po sve smrti).

Prakticky problem u toho Non-SQL je, ze rada lidi se eventuelne od jinak dobreho nastroje odvrati, protoze jim OODB prijdou prilis nove a tajemne a nemaji ten spravny pocit "samostatnosti", ktery maji napr. u mysql, protoze tam uz s phpmyadmin dokazali nejaky select zplodit.

I kdyz bude cela databaze "nejak" (co je nejak je zde ta otazka) odstinena, tak jsem zjistil, ze vetsina uzivatelu nejak intuitivne chce si v nejhorsim pripade na ta data "sahnout" ve vlastni rezii.

K tomu clientu - to je pro me jeden ze stavebnich kamenu toho vyvojoveho prostredi. Domnival jsem se, ze chapu co chcete delat, ale ted si nejsem jisty. Proto moje predstava:

- client je nejake exe a toto exe nema v sobe po startu zadnou aplikacni logiku - start muze trvat i nekolik sekund

- exe si natahne po startu z serveru nejake menu a vse ostatni potrebne

- uzivatel si vybere v menu nejakou polozku a klikne na ni

- v tuto chvili to exe natahne ze servru nejaky popis a na obrazovce se objevi to, cemu rikam "maska". Maska je tedy jedno z mnoha oken te aplikace. V tomto okne je tech 500 elementu (widgetu) a doba od toho kliknuti az k uplnemu zobrazeni toho okna by nemala presahovat 0.7 sekundy.

je vas postup podobny, nebo na to jdete jinak

[Messa]

Myslím si, že spousta lidí v životě objektovou databázi ani neviděla (přiznávám, beru to podle sebe). Možná kdyby bylo trochu osvěty…

[Pavel 'lingeek' Szalbot]

Osvěta? Třeba PostgreSQL (ale existují samozřejmě sofistikovanější systémy). Neplatí, že OODB -> nonSQL (a už vůbec ne naopak). A jak jsem se znovu utvrdil - spousta lidí si myslí, že relační databáze -> SQL.

[Kyosuke]

Myslí si to zřejmě vývojáři relačních databází, jak jsem tak koukal...

BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.

[Pavel 'lingeek' Szalbot]

BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.

Napsal jsem to blbě. Spíš tam měly být objektově-relační DB. Na druhou stranu jsou dnes ORDB používané více než čisté OODB... Přes úpadek aspoň dodám, že některé OODB se snaží podporovat i SQL, kvůli klasickým relačním úlohám, které jsou v nich hůře popsatelné (slušně shrnuté to je třeba ve Wiki).

SQL 2003 vychytávají spíše směrem k SQL/XML (paper).

[Kyosuke]

„Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support.“

Upřímně, já nevím, co se pánům nelíbí, ty chybějící „formální matematické základy“ mi přijdou jako FUD. Řádkové zamykání a řešení deadlocků v reálných implementacích – to jako podle nich má být ta „formálně lépe vyřešená“ věc? V tu chvíli je mi je matematicky čistý koncept relačního kalkulu naprd, když si díky takové věci jako je neexistence identit vynucuje takovéhle nesmysly... Podotýkám, že teorie pana Codda mi nesmrdí, jen vidím kolem sebe hromadu „SQL fanatismu“, aspoň mi to tak přijde.

„Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint.“

To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu. Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...

[Pavel 'lingeek' Szalbot]

To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu.

Nesmysl to podle mě není. Autor netvrdí, že objektová databáze deklarativní přístup neobsahuje, jen poukazuje na problém s přístupem k datům kvůli zapouzdření (querying on data content vs. predefined access paths). A v podstatě má pravdu, když říká, že objektové systémy jsou vystavěny na chování objektů. Na nutné (!?) deklarativní "zlo" lze nahlížet i jako na přežitek ze světa primitivních typů, ale to už odbočuji.

Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...

To už mi došlo, když jsi psal o generických funkcích a podvědomě asi ještě mnohem dříve (jak tě tak z diskusí znám). Smalltalk je mainstream?

[Kyosuke]

Deklarativní věci podle mě nejsou zlo. Právě naopak: Já chci postavit IS nad objetovou databází právě kvůli přímočarosti deklarativního přístupu. Jenomže „deklarativní přístup přes SQL“ mi přijde hrozně chudý, hromada věcí se v tom sémanticky ztráci. Já si radši ty věci vygeneruju z metajazyka než abych někde duplikoval kód v SQL a v logice aplikace. Objektová databáze mi umožní udělat si na míru deklarativně popsaný sytém, relační databáze by mi díky vazbě většiny RDBMS na SQL vnutila jeden konkrétní, poměrně rigidní, který by mi pro slušnou část dat ještě ke všemu nevyhovoval a já bych musel dělat separátní data ještě mimo databázi (vlastní fulltextová indexace a spol) a ještě to celé lepit dohromady v několika backendech a starat se o udržování konzistence...kdepak, děkuji, nechci. Prevalence to obslouží mnohem líp, dokud to nebude moc velké. To se hned tak nestane, ale pružnost budu potřebovat úplně od začátku (pár klasických tabulek, nějaký ten hypertext, fulltextový index, dost možná konfigurovatelný, hierarchické slovníky...). Prostě věřím, že dlouhodobě se mi v tom bude dělat příjemněji. A člověk se aspoň něčemu přiučí.

[Pavel 'lingeek' Szalbot]

Vždyť jsem zlo posadil mezi uvozovky. Možná jsi mohl být konkrétnější ohledně ztraceného významu, protože pokud jde o čistě deklarativní záležitosti, tak by relační model měl stačit. Že to nebude tak pohodlné jako objektový přístup, by mohla vyvážit vyspělost (doplň si aspoň 5 omílaných rysů jako robustnost, škálovatelnost... ne, nechi je shazovat) RDBMS. Ale možná bych být tebou uvažoval i o objektově-relačním systému. Co se vůbec chystáš použít? Jestli to není tajné, nebo doma vypěstované.

[Kyosuke]

Doma vypěstované to zčásti bude, ale s největší pravděpodobností bude velký kus postaven na balíku cl-prevalence. Nevím, no, jak moc dobře se z SQL – nebo ještě lépe z existující databáze – dají generovat rozumné formuláře? Třeba Ruby on Rails řeší problém „řešit každý problém na jednom místě“, ale hopsání mezi editorem struktury databáze a definicí třídy mě taky moc neuspokojilo. Asi jsem moc náročnej... Budu taky mít testovací vektor v podobě poměrně slušného množství překladů (šlohnutých z databází Microsoftu, ke kterým mám login ) a pokusím se zreprodukovat fuzzy matching TRADOSovské konkordance, když to bude poskytovat podobné nebo ještě lepší výsledky, ovšem nad daty z naší databáze s custom poli (autor termínu, historie změn, věrohodnost překladu), ušetří nám to integrací hromadu času a práce při překladech. Fakt nevím, jak bych to mapoval nad SQLkem, přijde mi to jako lámání přes koleno.

[Kyosuke]

Jakmile bude něco z toho hotové - asi v průběhu prázdnin - přihlásím se s prototypem, mohlo by to být docela zajímavé.

[Pavel 'lingeek' Szalbot]

O Tradosu skoro nic nevím, ale ten mě ani moc nezajímá - z kurzu lingvistiky ve mně ještě převládá skepse. Prevayler nicméně vypadá velmi zajímavě. Ach jo, asi bych Tě měl blokovat - je zkouškové! Ale Scalability Test si zkusím.

[happy barney]

imho, najlepsim riesenim multiplatformoveho klienta je HTML (popr AJAX).

v poslednej dobe sa mi zapacil OpenLaszlo, snad ma jeho existencia konecne dokope k dotiahnutiu svojho gui projektu do konca

[springer]

to ma radu nevyhod. Napriklad vzajenma interakce mezi jednotlivymi okny nejake aplikace. Nemluve o tom, ze na beznou stranku v HTML se dostane tak max 50% elementu, co se da nacpat na stranku, ktera je vytvorena pomoci nejakeho toolkitu (napr. qt). To vse jde jen tehdy, kdyz se to napise v Jave. Ale pak musi mit uzivatele nainstalovanou Javu.

[happy barney]

hmm, dobre, pripojim este skratku jednej horucej novinky .. CSS

ale viac ma do debaty o uzivatelskej privetivosti nedostanete. moj nazor je, ze design maju robit netechnici pre netechnikov, a technici - programatori vymysliet cestu, ako to vyrobit, nie ako to "osidit" (predsa len slusnejsie ako slovenske "oj*")

[springer]

mate pravdu, o vhodnosti webovych klientu se jiz diskutovalo dost. Chtelo by to srovnani techto dvou smeru s tim, ze by nejaky zakaznik vyslovil sva prani a pote by 2 tymy zkusily realizovat pozadavky, kazdy tym svou metodou. Znate nejaky takovy nastroj v html?