Database structure comparison

When migrating from DDM to Lotus Quickr, several things are important for the server administrator to keep in mind:

򐂰 Backend-database sizes

򐂰 Document spread per backend-database (number of documents per backend database and the total number of databases per server)

򐂰 Document spread per folder (number of documents in each folder)

򐂰 Server distribution

The choices that you make during migration might determine the flexibility and scalability of your server as well as the overall performance of your new Quickr environment.

Database size

In DDM, spawning is used to distribute large amounts of data over several databases. This is done transparently, meaning the user is not aware of it. Because of the limitations on

database sizes in older version of Notes (for example, four GB per database), spawning was an absolute necessity. However, even with support for larger database sizes (up to 64 GB as of Lotus Domino 6.5.1), it is still advisable to limit the size of the DDM database to manage the response time when opening a database.

For Quickr. the recommended solution for storing attached files that represent large amounts of data is to use DAOS. DAOS reduces the database sizes and allows you to put more data into one database. We suggest you use DAOS for your Quickr environment when importing DDM data into it.

To get an idea of the amount of data in your current file cabinets, you can total the sizes of all the document databases per DDM file cabinet. This is not an exact or definite number because the Notes documents themselves are also included (as well as any design elements), but this gives you a good indication of the size. This number includes all stored versions and drafts of each document. If you are planning to migrate only the latest version of each document, the total amount of imported data could be significantly smaller.

Chapter 7. Hierarchical and structural considerations between Domino Document Manager and Quickr 107

Document spread in databases

By document spread in databases, we mean the number of documents located in any single backend database. This is separate from the size of the documents.

Limiting the number of documents per database helps to improve the overall performance of your Quickr environment. Putting too many documents into one single backend database can make opening that particular place or room slow. However, do not go overboard in creating multiple places to avoid too many documents in any one place. Having thousands of databases on a single server can also have a negative impact on performance.

Within Lotus Quickr, the following elements each represent a single backend databases:

򐂰 Place (including the place library and any folders created in the place directly)

򐂰 (Sub) Room (and any folders created in the room directly)

If you have a DDM library with hundreds of thousands or even millions of documents, it might a good idea to split that up into several rooms or even several places. For instance, consider creating a place per file cabinet or per binder category depending on the document spread over the individual binders. On the other hand, if you have a library with only a few hundred of documents or a couple of thousand, then putting the whole library into a single place would most certainly be an option as well.

This does not mean that you cannot put larger numbers of documents into one place. It only requires that you use rooms and sub-rooms to divide the total number of documents over multiple databases if you exceed this. The advantage of doing this is that you can also include security at this level.

Document spread in folders

A folder is not a separate database but included in the place or room (or sub-room) database it was created in. The number of documents within a folder counts directly towards the total number of documents for the database.

The main consideration when determining how many documents you should put in a single folder is based on considering the user experience. You can put hundreds of documents in a single folder. However, having large lists of documents is not something users find easy to work with. By default, a typical Quickr view will list from 10 to 100 documents on a single page (based on user preference). Having many documents in a single folder will require the user to scroll to navigate and will increase the page load time for loading the lists.

Note: Determine the file cabinet data size by getting the database size of each of the

document databases. To locate the document databases for the file cabinet, go to the DDM directory on your DDM server and locate the databases that have the name of a file cabinet plus a number (the database with just a file cabinet name are the binder database and shouldn’t be included).

For each of the document databases, check the database size through the database properties.

To view how many document databases are in use, open the library database in a Notes client and double-click a file cabinet to open that cabinet’s binder database. In the

navigation ribbon on the left, click File Cabinet Administration. On the next window, click the option for Binder Administration. The view presented is categorized by replica ID of the document databases

You can take a lead from Google here, too. When searching with Google, you can get millions of hits for your search query, but if you cannot find what you are looking for within the first two pages, you are most likely to search again or lose interest. Nobody goes through all

thousands or millions of entry pages that the search produced.

A Quickr folder is, of course, not a search result, but the same principle still applies. If a user is looking for a particular document, he or she is not likely to scroll through pages and pages of listed documents to find the document they are looking for. The whole purpose of having a hierarchy structure (in addition to using it for security) is to lead your user through different levels of categorization to the specific document they are looking for without having to use the search functionality. If they reach the end of the hierarchy and still find hundreds of

documents, they could lose interest or the need to use the search functionality anyway. Use the folders to distribute the documents in such a way that the hierarchy supports a logical path to the user, as well as any security measurements that you require.

Do not nest too many folders. It is considered an annoyance for users. Windows OS (for example, usage of Quickr through the connector) limits the total file path to 254 characters, after which names are truncated and some programs might have problems accessing the files.