Do I Need Only One Personal Knowbase Data File or More? (Part 2)

Personal Knowbase users often struggle with the decision of when they would want more than one PK data file.

In Part 1, we talked about starting with a single file and using multiple files when they serve completely different purposes. Here are some additional issues with using one or more database files.

Advantage of a Single Data File

The main advantage to having all of your data in one file is simply to be able to view the data together. This is a deceptively major point.

Each Knowbase data file is a distinct entity with no connection to other data files. There is no way to link between files, list articles from more than one file together, create reports containing articles from multiple files, share keywords, or search for text across files.

Yes, you can open as many files as you want at the same time, each in its own Personal Knowbase session. But those PK sessions are distinct, and each session only works with the articles and keywords in its own open file.

When you want to use your data together, store it all in one database. Otherwise you'll be flopping back and forth between files constantly.

For example, I know one customer who uses PK for historical research and has just one large database with thousands of articles. That makes sense for him.

Searching Multiple Data Files

The most common complaint with keeping multiple files is the inability to search for text across separate files. You can only search one file at time. The Find command only searches the current file open in the current PK session.

But if you have multiple files, a compromise is to search the files consecutively from within the same PK session. See our previous Tip about Finding Text across Multiple Knowbase Data Files.

File Sizes

Users sometimes worry that if they throw all their notes into one data file, it will become too large or hit some limit on the number of articles.

Personal Knowbase has no technical limit on the number of articles or keywords. Don't worry about this factor when starting out. You can always split a file later.

As files grow very large, access times slow down. This is mostly an issue when searching text and exporting to RTF format. You are unlikely to notice any degradation until you have tens of thousands of articles, depending on your articles' sizes and hardware speed. The same applies to tens of thousands of keywords.

If you experience slow Find operations, see your Tip on Running a Faster Find.

Splitting and Merging Files

If a group of articles warrants its own data file, you can split them out by exporting them to their own new file. Or you may decide to split out old obsolete articles into an archive file. After setting up the new file, you can go back and delete the exported articles from their original file.

Similarly, you may decide that a data file didn't develop as you expected or that a subject no longer needs its own space when a project finishes. If you want to roll it back into your general file, you can merge it without re-entering your data. Merge files using the Import command. You can even assign one or more keywords to all of the incoming articles from the imported file, for example to tag them with the project they came from.

But everyone's situation is different. We're all storing different notes for our own purposes and projects. Create a new file when a project needs its own container.

Whatever you decide now doesn't commit you long-term if you change your mind later.