Monthly Archives: January 2007

Firebird Embedded and .NET

Firebird Embedded is a very popular, special, version of Firebird database engine. The main advantage is, that there’s no need to install it. Not to bring some wrong information, it’s not some crippled down version (there are some limitations, but it’s the being embedded consequence) – it’s the fully-featured database engine. For those, who don’t know what Firebird is or just want to discover what this – more than twenty years audited – engine is able to do, can study this document – it will not take more than two minutes.

Let’s get back to the FB Embedded and .NET. So, what we’ll need? Of course, the Firebird. You can download it from http://www.firebirdsql.org/ pages, current version 2.0 particular from http://prdownloads.sourceforge.net/firebird/Firebird-2.0.0.12748-0_embed_win32.zip. The second stuff we’ll download is Firebird ADO.NET Data Provider. It’s available for .NET Framework 1.1, 2.0, Compact Framework 2.0, Mono 1.1.18+. DDEX Provider for Visual Studio 2005 is available too. Download version that fits your needs from http://www.firebirdsql.org/index.php?op=files&id=netprovider. Cause‘ we want not to do any installations on machines (except the developer’s machine) we will use only necessary files:

  • FirebirdSql.Data.FirebirdClient.dll
    • .NET Data Provider assembly
  • fbembed.dll, icudt30.dll, icuin30.dll, icuuc30.dll
    • files of Embedded FB

Except these necessary files is there a couple of files, that are not absolutely required, but it’s good to add it into pack:

  • aliases.conf, firebird.conf
    • files for Firebird configuration
  • intl\fbintl.conf, intl\fbintl.dll
    • files that supports working with international character sets

Note: On some systems or configurations aren’t available libraries msvcp71.dll and msvcr71.dll. These you’ll find in downloaded package too and if required distribute it together with application.

Creating an application is then a minute. Just add into references FirebirdSql.Data.FirebirdClient assembly and add near to program fbembedd.dll (or generally into place, where system tries to load DLLs by default). Some example of “well-configured” Firebird you can find here (note: files are after build copied into bin directory on top level, so from this location you have to run it).

As I said on beginning, Embedded Firebird has some limitations, and it’s good to know about these during choosing database platform. First is the necessity to connect to database only thought local protocol, so the TCP/IP connection using “localhost” or “127.0.0.1″ will not work. The next is, that Firebird isn’t doing any checking during connecting (and it would not make sense, because client and server are in same address space). Permissions to database object are applied of course. The last limit is fact, that embedded version isn’t good (but can work) for ASP.NET environment, cause’ the file is exclusively locked during first connection by this application.
On other side, very positive is difficulty of moving into “normal” Firebird server. You’ll just modify connection string and everything else will work in same way – no other changes, no code changes. You can scale your application from one user up to thousands without any additional effort.

Today we showed how easy can be using Firebird in embedded environment, with keeping full SQL and ACID functionality.


Czech version originally created for vyvojar.cz.

 

Logování baťáků

Uchovávám si logy z různých skriptů, které automaticky spouštím pro pozdější prozkoumání. Ale řešil jsem, jak jednoduše zajistit zápis do logu (občas někde něco člověk zapomene) a případně jeho potlačení. Nakonec jsem vymyslel jednoduché řešení:

@echo off 

if "%1" NEQ "CALL" (
call %0 CALL > batak.log
goto finito
) else ( 

 rem prikazy ...
goto finito 
) 

:FINITO

Ukládat obrázky do DB???

Tento post chci napsat již dlouho. Ale pořád jsem buď neměl čas nebo chuť či odvahu. No ale nakonec se hvězdy dostaly do správné konfigurace a píšu.
 
Slyšel jsem hodně názorů ohledně ukládání obrázků do databáze (nebo obecně souborů, ale většinou se toto řeší s webem apod.). Zajímavé je, že většina lidí argumentuje stále tím samým a vždy říkají, jaké to má ohromné nevýhody. Nicméně nikdy jsem ještě neslyšel názor, který by přihodil i nějaké výhody a provedl zamyšlené porovnání.

Proč tedy všichni tak striktně odmítají uložení obrázků do DB? První argument, který každý vytasí je rychlost resp. pomalost. Nedělal jsem žádné podrobné testy pro určitou platformu, ale je jasné že to musí být o něco pomalejší je přece další vrstva mezi aplikací a souborem. Dalším argumentem je většinou velikost DB, to je celkem nepopiratelné. A nakonec “na bedně” máme ještě – trochu slabší, ale … – že “taková” data do DB nepatří.

Nejsem odpůrcem ani zastáncem ani jedné strany (i když otevřeně říkám, že neodmítám ukládání obrázků apod. do DB). Pojďme se ale podívat na vítěznou trojku a zkusit se nad tím zamyslet. Tedy třetí argument, ten mi připadá úplně “nejblbější”. Proč by proboha obrázky v DB nemohly být? Jsou to přece data jako každá jiná a chci-li s nimi takto pracovat není na tom nic špatného. Další. Velikost databáze. Jasně, když jsou tam data, musí místo zabrat. Kdyby byly na disku, tak taky místo budou zabírat. Je pravda, že s větší DB se hůře pracuje (zálohy, obnova, přesuny, …), ale neviděl bych to jako velký problém – můžeme ho přece lehce vyřešit např. rozdělením. A osobně nemám s velikostí problém – a pokud by snad nějaká DB mělo mít problémy s tím obsluhovat “velkou” DB nezaslouží si nic než zahodit. No a první – pomalost. Nevím o kolik procent mi toto sníží výkon, takže budu spíš polemizovat. Podívám-li se na to, ale z druhé strany, tak jako tak dříve nebo později nebude rychlost vyhovovat. Buď je třeba posílit HW nebo použít mozek – např. cacheování. Když to tak vezmu, tak s obrázky v DB si akorát trochu zkracuji tu cestu do fáze, kdy mi výkon nebude stačit. Pokud půjde použít mozek, paráda, můžu to lehce vyřešit. Pokud půjde o HW a nedělám projekt, u kterého nečekám růst (kdo by to dělal?), tak s růstem bude určitě třeba povýšit i HW. Ale je pravda, že všechny tyto věci jsou zbytečné nebudou-li obrázky v DB. Dobře tento argument beru – nemůžeme jej popřít ani potvrdit.

Co se ale podívat na výhody uložení v DB? První co mě napadne je určitě výhoda v podobě transakčního zpracování. Nikdo mi nevymluví, že transakce jsou skvělá věc. Pokud máte na aplikaci, která právě taková data zpracovává není nic lepšího než využít všech možností transakcí a constraintu apod. věcí. Nemusím se pak spoléhat na aplikaci, že vše udělá správně. Můžu to nechat na DB a můžu si taky DB updatovat přímo z konzole, což se někdy může velmi hodit. Další věc co mě napadá je zálohování a archivace. Pokud mám jednotné úložiště, vše je jednodušší. Co dál? Co třeba přístup z více míst najednou? Mám-li už jednou přístup do DB mám rovnou i přístup k obrázkům (ne že by nešlo vzdáleně pristupovat na FS, ale když už do DB pro jiná data musím, je to pak o starost méně). No a poslední věcí (co mě napadlo, né celkově) jsou práva. Když už jsem se patlal s přístupem k jiným datům v DB, tak udělat to nad tabulkou “obrazky” nebude mnoho práce navíc.

Chápu, že celý tento text je poněkud kontroverzní, a určitě přide někdo, kdo řekne “ty si ale pako, obrázky do DB nepatří a prostě nemáš pravdu” – já netvrdím, že tam patří (nebo nepatří), jen jsem se chtěl podívat na argumenty, kteří zarytí odpůrci používají.

Nejsem zastánce ani jednoho extrémního řešení, vždy si to chce celou věc pořádně promyslet.