The first step to efficiently use Tamino is to get the data model right. The following aspects should be considered:
The document types should implement whole business objects and documents. You should avoid "relational" designs such as first Normal Form. Business objects represented by an ensemble of flat tables are not suitable for native XML databases. In some cases, however, it may be necessary to split a large business object into several documents.
Avoid large documents. Large documents can slow down processing considerably. For example the current Tamino version compresses documents larger than 32 KB to save disk space and to speed up disk access (see also document Result Size). However, it is possible to "reassemble" many small documents back together into one large document by using joins and projections in XQuery.
Also, when a single document contains several business objects, you may run into performance problems due to locking conflicts. Because locks are set on the document level, you would lock all business objects contained in the updated document, even if a certain business object is not affected by the update. This will prohibit other users from concurrently accessing or updating these business objects, depending on the isolation level.
If a document contains clearly identifiable "hot spots" and "cold areas", i.e. a small area is accessed frequently while another large area is accessed only rarely, consider separating these two areas into two documents. This will increase the processing speed for the frequently accessed area.
Sometimes it can be appropriate to re-introduce redundant data elements in order to speed up retrieval. The downside to this is that updating becomes more complicated and takes more time.
