Portál AbcLinuxu, 30. dubna 2025 20:27
26.5.2006 19:34
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
) 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. 
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.
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
.
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.
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).
„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“...
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?
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čí.
. 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é.
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.
. Prevayler nicméně vypadá velmi zajímavě. Ach jo, asi bych Tě měl blokovat - je zkouškové! Ale Scalability Test si zkusím.
v poslednej dobe sa mi zapacil OpenLaszlo, snad ma jeho existencia konecne dokope k dotiahnutiu svojho gui projektu do konca
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*")
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.