Jiří Hradil blog

o software


Téma: ukládání dokumentů na serveru

Představme si následující situaci. Máme vlastní informační systém, který běží na straně serveru (na Javě, PHP…) a klientům zasílá vygenerované HTML či XHTML stránky.
Hlavní komunikaci klienta se serverem zprostředkovávají formuláře.
Systém by měl fungovat jako datový sklad pro dokumenty, uploadované na server společně s připojením popisných údajů-vlastní název souboru, poznámky, propojení s nabídnutým číselníkem, atd.
Popisná data dokumentu budeme ukládat do databáze, ale co se samotnými dokumenty, které můžou být také binární data-obrázky, mp3, všemožné doc, xls?

Nabízí se několik možností:

Popisná data uložíme do databáze (DB) a dokument přímo do filesystému (FS) na serveru. Součástí popisných dat v DB bude odkaz na tento dokument ve FS.

  • + Dokumenty ve FS je možné sdílet a přistupovat k nim i jinak, než jen přes rozhraní systému. Třeba jen pro čtení. V Linuxu lze nastavit sdílení složky s dokumenty např. přes Sambu a klienti mají možnost otevírat soubory přímo ze serveru, což může být někdy rychlejší, než přistupovat přes browser.
  • + Dokážeme tak ukládat i velké objemy dat (mnoho velkých dokumentů). Protože databáze uchovává pouze popisná data, mohla by být menší a rychlejší.
  • +/- Data na dvou místech - pokud spadne DB, dokumenty máme jinde (řeší kvalitní záloha). Avšak musíme se starat o zálohu dvojí.
  • - Obtížná implementace fulltextového prohledávání dokumentů. Pokud umíme pracovat s určitým typem dokumentu, pak výsledky vyhledávání zřejmě budeme muset taky ukládat do databáze. Pak by v DB byla popisná data a výsledky fulltextu. Odkaz na dokument ve FS.
  • - Neustále je třeba kontrolovat konzistenci dat, pokud se smaže dokument v DB, musí se smazat i ve FS a naopak. Tohle je asi největší problém.

Vše uložíme do DB. Binární data dokumentu budou jako datový typ blob, bytea, large object, apod.

  • + Vše na jednom místě. Vyřešíme tím dokonale provázání popisných dat a dat dokumentu.
  • + Fulltextové prohledávání (pokud umíme s daty dokumentu nějak pracovat) bude řešit DB.
  • ? Rychlost a náročnost DB. Tady opravdu netuším, jaké bude mít DB odezvy, pokud v ní budeme mít několik GB dokumentů.

Téma: Co si myslíte o jednotlivých řešeních? Napadá vás nějaký jiný, rozumný a pokud možno co nejjednodušší návrh?

Publikoval Jiří Hradil • 28.04.2004 v 23:04 • pod kategorií Nezařazené • 6 komentářů

Gmail Beta - první dojmy

Jakožto uživatel systému Blogger jsem využil nabídku být jedním z prvních uživatelů, kteří můžou vyzkoušet službu Gmail (nyní v betaverzi). Jedná se o webmail, rozšířený o řadu netradičních funkcí:

  • + Jednoduchost. Skutečně, klientské rozhraní působí velmi střídmě a přehledně.

  • + Zprávy se netřídí, ale prohledávají (velmi rychle a jednoduše). Tato funkce je pro mě jednoznačně nejužitečnější.

  • + 1 GB volného místa (bezesporu nejlákavější marketingová nabídka :)

  • + Seskupování zpráv (pokud přijde email a odpovím na něj, v detailu emailu je vidět předchozí konverzace).

  • +/- Reklama - absence vyskakovacích oken s reklamou. Systém velmi rychle pozná, odkud jsem přišel a nabízí mi statické reklamy na české stránky. Gmail by měl primárně těžit z cílené reklamy, která odpovídá charakteru textu v emailu. Toto “vylepšení” však bude zřejmě ještě upraveno. Test: poslal jsem si mail s předmětem “notebook LCD monitor” s textem “musím koupit nový hardware, software, najíst se v restauraci a vyspat v hotelu!” a Gmail mi nabídl jen reklamu na koupi luxusních bytů v Praze, o HW a SW ani zmínka :). Současný způsob reklamy však nepůsobí agresivně a dá se vydržet (možná jsem již tak otupělý reklamou ze všech možných médií, že mi tato připadá taková… neškodná :).

  • + Řazení zpráv do skupin (labels). U každé zprávy lze rozhodnout, kam obsahem zapadá a pak ji dle vytvořené a přiřazené skupiny jednodušeji filtrovat. Je to v podstatě taková obdoba složek. Klasické složky (adresáře) nelze v Gmail vytvářet. Existující složky jsou pevně dané. Docela revoluční nápad, uvidíme, jestli mi jednotlivé složky budou chybět. Myslím však, že vše dokáže nahradit účinné prohledávání (a to již dal Google Gmailu do vínku).

  • + Spolehlivost (aneb neříkej hop…). Ale je to přece jen Google, takže se dá očekávat vysoká rychlost a spolehlivost v ostrém provozu. Prostě jim věřím :)

  • + Spam filtr. Nevyžádanou zprávu lze označit ručně jako spam a systém se podle těchto informací učí.

  • + K dispozici je i nastavení filtrů po příchozí zprávy a nastavení prohledávání.

  • + Příprava pro tisk.

  • + Klávesové zkratky (jen část, seznam je dlouhý. Fungují i comba, např. g+i).

  • +/- Kontrola pravopisu, chybí však čeština. Snad jen dočasně.

  • - Adresář je jednoduchý, ale v tomto případě možná až příliš. Chci víc položek!

  • - České rozhraní chybí. Avšak čtení a odesílaní českých emailů funguje bezchybně. Google používá UTF-8. Kdo pomůže s překladem?

  • ? Externí klienti (POP3?) V budoucnu měl být systém dostupný také přes externí klienty (zdarma či za minimální částku).

Závěrem: Jsem mile překvapen, jak přehledný a jednoduchý může webmail být. Pokud se nebude zvyšovat procento agresivní reklamy a bude zachována jednoduchost, tento webmail bude u mě s přehledem nejoblíbenější.

UPDATE 28.04.2004: V komentářích reaguji na některé části příspěvku “Gmail: Nejhorší webová aplikace” z About weblogu.

UPDATE 07.05.2004: Po přihlášení mám možnost pozvat 2 kamarády, kteří si pak můžou zřídit vlastní testovací přístup. Takže prvním 2 zájemcům, kteří se mi ozvou na můj mail tuto pozvánku rád zašlu (potřebuju jen platný mail).

UPDATE 08.05.2004: Pozvánky rozeslány.

Publikoval Jiří Hradil • 26.04.2004 v 23:04 • pod kategorií Nezařazené • 4 komentářů

Předávání parametrů Java programům

Java Boutique popisuje několik způsobů, jakými lze předávat parametry našim Java programům:

  1. Parametry (argumenty) příkazového řádku
  2. Soubory vlastností (property files)
  3. Kombinací 1. a 2.
  4. Systémové vlastnosti (system properties)
  5. XML soubory
  6. Databáze
Publikoval Jiří Hradil • 06.04.2004 v 11:04 • pod kategorií Nezařazené • Žádné komentáře