Frequently Asked Questions

How do I start using Qizx/db ?

The documentation contains a chapter titled "Getting Started". Qizx is a class library that comes with two applications: Qizx Studio a graphic interface, and a command-line tool to run scripts.

What is the difference between Qizx/open and Qizx/db ?

Qizx/open is essentially a cut down version of Qizx/db, it has no database and indexing engine. But it is fully open-source (under Mozilla Public License), while Qizx/db is not, though a large part of Qizx/db's source code is of course the same as Qizx/open. There is a comparison matrix here.

How do you pronounce Qizx ? What does it mean ?

Pronounce "Quiz X". It was originally an acronym for Querying Indexed Compressed(=Z) XML.

May I use Qizx/db Free Engine in a corporate application ?

Yes, the Free Engine may be used in an in-house application, even in production. Remember however that the databases handled by Qizx/db Free Engine are limited to about one gigabyte of XML in size, and that you have no support from XMLmind. For more details, please consult the license here.

May I embed Qizx/db Free Engine in a commercial product ?

No. You may not redistribute Free Engine in any way. Please consult the license here.

How can I use to Qizx/db from my .Net application (or from C/C++, PHP, Python, etc)?

Currently, Qizx/db is an embeddable engine written in Java. You can use it to implement a J2EE Web Application, so it will be usable from any web client.

We will also release a Server Edition, where Qizx/db will run as a separate server than can be used as a data source (back-end or middle tier) by various applications written in various languages. The server mode of Qizx/db Milestone 1 was based on Java RMI, which was not satisfactory in this respect, hence its withdrawal.

In Qizx/db Milestone 1, there was a functionality for retrieving data from SQL relational databases (called SQL Connectivity). Why is it no more available ?

This functionality is under redesign. The extension in M1 and Qizx/open was a rough-and-ready solution. The new version will be more evolved, with some automatic translation from XML Query to SQL.

I believe that Qizx/db's inability to update at the node level is an issue for my applications. What is your answer ?

It is a fact that many Native XML Databases (NXDB) support updating of individual XML nodes. In our opinion this capability is not absolutely indispensable and moreover has a perceptible impact on the speed of certain types of queries (namely intersections and structural joins). The design choice made in Qizx/db allows such queries to run considerably faster than in other XML databases.

Now where is the trouble for your application?

• When your application really needs to write a complete XML document to the database, Qizx/db does it efficiently: import with full indexing runs at up to 2 megabytes of XML per second.

  This is a common use case in document-centric systems: a document is extracted in full, processed by an editor or other tool, then written back to the database.

• If you want to perform small updates in documents:

  • As long as the document size is under about one megabyte of source XML, it is OK to rewrite that document entirely into a Qizx/db database after updating. Maybe it will take slightly longer than in other databases (supporting node updates), but the cost will quickly be paid off by faster read-only queries (remember than read-only queries are in general much more frequent than updates).

  • If you have to update larger documents frequently, then perhaps we should give a thought to the design of your database. It is very likely that you would have some XML elements (such as item, invoice, customer...) existing in large lists inside your documents.

    If such elements are not too small (i.e their contents represent at least a few hundred bytes in XML form), then it is perfectly OK in Qizx/db to store each of them inside a separate small document. These small documents can be gathered in specific collections (named for example: items, invoices, etc.)

    By doing so, querying would be quite as fast, and updating would be performed with the best efficacy.

    You could object that it changes the schema of your database. But firstly Qizx/db does not require schema, so that would be painless. Secondly, we assume that if you use XML, it is precisely to benefit of its flexibility. Using a Native XML Database like Qizx/db fully builds on this flexibility.