[Lazarus] Web development and XML database (Mattias)

[michael.vancanneyt at wisa.be]

On Thu, 17 Nov 2011, Juha Manninen wrote:

> 2011/11/17 Mattias Gaertner <nc-gaertnma at netcologne.de>
>
>> It's a lightweight database for XML files. That means you give it a list
>> of directories and it will load/parse all xml files including
>> subdirectories into memory for fast access.
>> You can query via simple HTTP requests and get xml. So you are not
>> limited to FPC, you can use any language.
>> There are several types of query, including some with XPath
>> expressions. At the moment it supports only a few XPath features, but
>> they are already quite powerful.
>> When a file was edited/changed you can trigger a rescan or you can
>> rescan in interval. A rescan on a thousand directories to search for
>> modified files usually takes 10-100ms and is done in separate threads to
>> not disturb the queries. It parses about 5-20MB per second per core and
>> automatically uses all cores.
>>
>> It is currently used by two projects, that were migrated from eXist DB.
>> One is running on an OS X server, the other on a Linux server. They
>> have thousands of directories, more than 150MB of XML files, which
>> refer to others in various ways.
>
> [...]
>
> Thanks for the explanation.
> In essence it is a database optimized for reading but not writing.
> For updating the XML file contents there is no concurrency checks or atomic
> transactions.
> That is fine with many use cases but for example e-commerce sites could not
> use it. They need safe transactions for user profile and sales action
> management.
> This is partly why the SQL databases are slow, they take care
> of concurrency also when data is updated.

I really don't see why you think SQL databases are slow. We have lots of
queries running on our system, huge amounts of updates, and Firebird does 
an extremely good job of it, and we do almost only multi-table select 
queries. Concurrency is not an issue at all with their multi-generational 
architecture - no locking is needed.

Michael.