|
|
|
| About Databases |
|
|
| Figure 1: Relationship Between Data Elements in Plato |
|
A database is a collection of:- objects
- data structures that define the objects
- a few special indexes for managing the objects
- concordance (optional)
- list of cross references (optional)
- a collection of settings that allow you to tweak the way the database behaves
All these are contained together in one file which is saved to disk (or cloud, or other storage device) between sessions. Databases are closely coupled with class libraries and generally should be set up to synchronize with a parent class library. However, databases contain all the necessary data structures to stand alone and are therefore portable.
Databases must be loaded via the database list. Plato does not allow a database to be loaded directly from the file system via file associations. Plato databases may be stored in plain text form, which would allow them to be loaded into text editors, but when loaded into such editors features such as cross references and concordance would not be functional.
Figure 1 shows how the data structures in a database relate to structures in the class library, and how the class library is in turn built from smaller data elements.
|
|
| The Database List |
|
|
| Figure 2: The Database List and Edit Pane |
|
The database list is Plato's means of managing all your databases. Access to databases is provided solely through this list so that Plato can keep track of which objects the various databases contain.
The database list contains the following elements (top to bottom--see left portion of figure 2):- List selection drop down Allows you to select the database list (shown in figure 2, left portion) or the class library list.
- Console button Clicking on this button opens the window status console.
- Database List/Create database tab Clicking on a tab reveals the database list or the 'create database' pane (more on which below)
- Database List The list is sorted alphabetically by title. It contains the following columns: title, description, and class library.
- Properties/Categories tab Clicking on a tab reveals database properties or the category list (more on which below)
- Properties Displays read-only database properties:
- Database ID
- Database file name
- Database file format
- Database status
- List of object classes in the database
Editing Database List Properties
Each item on the database list has certain properties that are editable. Select an item from the list and right click on it, then select 'edit record' from the pop-up menu. The database editing pane will appear (see figure 2, right portion).- Database Title Descriptive title. This is what will be displayed in the drop down database list
- Database Description Longer description
- Database Filename
- Category
- Class library
- Display in drop down menu
- Backups
|
|
| Creating a Database |
|
|
| Figure 3: Create Database Pane |
|
Use the 'create database' pane to create databases. Fill in the following fields and press 'create' to add the new database to the list.- Database title Mandatory field. A simple descriptive title, which will appear at the top of the database window when the database is loaded, and will appear in the drop down database list.
- Database file name Mandatory field. Filename for the database, conforming to standard Windows file naming conventions. Don't include the path or the extension. All databases are stored to the same path, and Plato will automatically supply the correct extension when the file is created.
- Description Optional field. More lengthy description of the database, which will appear in column two of the database list display.
- Category Optional field. Supplying a category label can help organize the database list, which can be filtered by category.
- Class Library Mandatory field. The database will be attached to the class library you specify here. Databases should be attached to a class library because the class library is the source of new objects classes (for creating objects) and markup (for use in scripts).
|
|
| Database Categories |
|
|
| Figure 4: Editing Database Categories |
|
Database categories may be used to organize and filter a long database list. Click the 'categories' tab in the lower portion of the database list to access categories. Double-clicking on a category will cause only databases of that category to be displayed on the list. To display all the database categories, double-click the 'all' category.
To edit categories, press the 'edit categories' button and the 'edit categories' pane will be displayed. From this list you may add, delete, or rename categories.
|
|
| Database File Management |
|
|
| Figure 5: |
|
Databases can be stored in two formats, text and binary.
Database Related Files
Databases may also have several ancillary files associated with them for various activities. These files will have the same name as the database but with different extensions. Here is guide to these extensions and what they mean. Note, however, that these are the default extensions and can be changed by the user.- [database name].lst Main database file
- [database name].scr Database script file. This extension is only used when the 'store notes in database' property is unchecked.
- [database name].not Database note file. This extension is only used when the 'store notes in database' property is unchecked.
- [database name].clu Database cluster file. This extension is only used when the 'store notes in database' property is unchecked.
- [database name].jnl Database journal file. This file is used to restore changes to the database in case a power failure occurs before you've saved your work. The file is automatically deleted whenever the database is saved.
- [database name].whx Database word history list file.
- [database name].wordlist.bin Database concordance file. This extension is only used when the 'store notes in database' property is unchecked.
- [database name].wordlist.txt Database concordance wordlist.
|
|
| Database Properties |
Databases have many configurable properties that are detailed below.
|
|
| Properties, Description |
|
|
| Figure 6: Database Properties, Descriptive |
|
|
|
|
| Description properties describe the database--title, short description, extensive explanitory notes. All except the title are optional. When you change and of the desription properties, the database list will automatically be updated when you set the 'synch description with datatabse list' property to 'on.' |
|
|
title |
This is the descriptive title for the database. It will be the primary description of the database that will appear in the database list and on the database window's control bar.
|
|
category |
The database category is a way of classifying databases by subject matter or other criteria you may want to set up. Databases can them be sorted by catagory in the database list, or the database list can be filtered to display only databases of a certain category.
|
|
description |
A more verbose description of the database that you may provide in addition to the database title. This property appears in the database list.
|
|
notes |
This may contain more detailed notes about the database. The field is limited to 30K bytes of text. The content of this field will by displayed in the 'about this database' window |
|
synch descriptions with db list |
Setting this property will cause any changes to the database description fields to be synchronized with the same data in the database list (and vice versa).
|
| Properties, Display and Performance |
|
|
| Figure 7: Database Properties, Display and Performance |
|
|
|
|
Display properties let you adjust how certain basic elements of the database pane are displayed.
|
|
|
folder types to show |
This setting controls which folder types to display in the folder tree. Plato considers any object class with the "open as folder" action to be a potential folder. This setting displays all the object classes with "open as folder" actions and allows you to check the ones you want displayed in the folder tree. The default is "folder." |
|
first folder to load |
Stipulates the first folder to load when the database opens. You may pick from a list of all available folders in the database. This setting only affects databases saved in text format; in memory-image format, Plato will automatically open the folder you had open when you last saved the database. |
|
hide system chat |
Hides the system chat display from the database pane.
|
|
hide database chat |
Hides the database chat display from the database pane.
|
|
hide folder chat |
Hides the folder chat display from the database pane.
|
|
hide object chat |
Hides the object chat display from the database pane.
|
|
Default object display |
This setting which object properties are first displayed when you open the object view pane. Choices are "notes" and "properties;" the default is "notes." |
|
auto-select object display |
This property affects how notes are displayed in the object property pane. If the default object display is set to "notes," this setting will override it if the note field is empty, and display the object's properties instead. The setting has no affect if the default object display is set to "properties,"
|
|
performance: slack records |
This setting controls the number of slack records the database will maintain. |
| Properties, Inheritance |
|
|
| Figure 8: Database Properties, Inheritance |
|
|
|
|
Inheritance properties let you set inheritance rules for databases settings and folders.
|
|
|
default object class |
The default object class is used to determine |
|
default xref type |
Sets the default xref type. In xref creation dialogs, the xref type set here will display as the default.
|
|
object class for clipboard imports |
This property defines |
|
template for normal folders |
This setting allows you to select a folder for use as a template when new folders are created in a database. All the properties of the template folder will be inherited by the newly created folder (except for the name of the folder). |
|
template for scratch folders |
This setting allows you to select a folder for use as a template when new scratch folders are created in a database. All the properties of the scratch template folder will be transferred to a newly created scratch folder.
|
|
use folder object class for clipboard imports |
When this property is set, clipboard imports will use the folder's default object class. |
|
xrefs: auto-build xref maps |
Yes/no setting. When yes, xref maps will be built automatically whenever xrefs are displayed. |
| Properties, Validation |
|
|
| Figure 9: Database Properties, Validation |
|
|
|
|
| Validation properties set rules for validating data in the database when it is loaded or saved. |
|
|
class library consistency |
Checks to see if database objects are consistent with the object classes in the class library. If there are newer versions of object classes in the class library, the database will be updated with the newer versions. |
|
cross reference consistency |
Checks to see if cross references correctly reference real objects in the database. If discrepancies are found, the function will attempt to correct them. If they cannot be corrected, they are deleted from the cross reference table.
|
|
folder validation |
Checks to see if each folder item points to the correct record, and corrects the folder reference if possible. If the folder reference can't be resolved it is deleted. For large databases with big folders (i.e., hundreds or thousands of items) this check can be time consuming. The default setting is "off" (i.e., unchecked). |
| Properties, Omit Lists |
|
|
| Figure 10: Database Properties, Omit Lists |
|
|
|
|
| These omit lists control which words are excluded when folders are sorted and when title case is determined. |
|
|
omit list for folder sorts |
Works in this list are ignored when sorting items in a folder. |
|
omit list for title case |
Words in this list are dealt with specially when Plato determines the title case of a sentence or heading. Words listed here are not capitalized. Words listed here in brackets are treated literally. This is useful in preserving acronyms. |
| Properties, File and Backups |
|
|
| Figure 11: Database Properties, File and Backups |
|
|
|
|
| These properties control database format and how they are saved and backed up. |
|
|
save database to format |
This setting specifies the format in which the database will be saved. There are two choices:- Text This is special plain text format that captures Plato records, cross references, notes, scripts, clusters, and settings in a modified comma seperated value format. This format is currently intended for manual debugging and can be slow to save and load, however it will allow you to edit the entire database in a text editor. See xxxx for the details of the text format.
- Memory Image This is Platos native format. It loads and saves very quickly but it can only be deciphered by Plato.
|
|
store notes in database |
When this property is unchecked, notes, scripts, and cluster data are stored in individual files seperate from the main database file. |
|
scratch folder action on database save |
Defines what to do with scratch folders when the database is saved. This setting has three options: 'always purge scratch before saving', 'never purge scratch before saving', and 'ask before purging or saving scratch'. |
|
undo mode |
This setting allows undo parameters to be tailored. Possible settings are:- enable undo and auto recovery
- enable undo, disable auto recovery
- disable undo and auto recovery
|
|
number of backups to keep |
This setting specifies the number of backups that will be maintained. When the maximum number of backups is reached, Plato will delete the oldest backup when a new backup is added to the list. |
|
backup filename extension format |
Defines the filename format for database backups. This is a read-only property that can't be changed. When a database is saved, the previous version of the database is automatically saved as a backup. This format specification tells Plato how to format the file extension.
|
|
current backup count |
Displays the current number of backups for the current database. This is a read-only property.
|
| Database Maintenance Routines |
|
|
| Figure 12: Special Database Maintenance Routines |
|
Databases contain many indexes and tables that are not visible to the user but are used to maintain objects and provide all the linkages necessary to cross reference and display them. Plato maintains these indexes automatically and performs clean-up chores behind the scenes as necessary. All of this 'behind the scenes' activity can be recorded in the activity log. The activity log is useful in tracking down problems if for some reason things get out of whack.
Most of Plato's behind the scenes maintenance routines can be run manually and if you suspect something is out of whack running them manually may set things right. Here are the available maintenance routines:- Rebuild database object class tables Plato maintains tables that link all database objects to object classes, all object classes to their attributes, and all markup to the object classes they act on. This routine will rebuild all of these tables from scratch.
- Clean up database indexes Plato keeps several internal indexes and databases to manage bookmarks, pick lists, categories, and the like. This routine will rebuild all of these indexes from scratch.
- Clean up folders Plato folders are essentially lists of a special variety of cross reference. This routine checks each folder cross reference, corrects it if necessary, and rebuilds the master folder reference list from scratch.
- Clean up cross references Plato manages a master list of cross references and various sub-indexes that facilitate cross reference performance. This routine checks each cross reference, corrects it if necessary, and rebuilds all the cross reference related indexes and lists from scratch.
- Clean up stranded text Errors caused by bugs may sometimes leave large blocks of text stranded throughout the database. This is a harmless condition functionally but until the stranded areas get reused the space is wasted. This routine clears out all stranded text from the database.
- Rebuild object descriptions Object descriptions are created whenever you create a new object or change an existing one. But if you remove attibutes from an object class, the class library / database synchronization will not always extend to recreating the descriptions, in which case your descriptions may contain text from attributes you've removed. This routine will rebuild all the object class descriptions in the database, one by one. If you have several thousand objects in the database, this might take several seconds to complete.
- Clear folder access logs Plato keeps a record of how many times a folder is accessed and records the last time it was accessed. This information is used when you 'clear' the folder history list--only very old or seldom used folders are removed. This routine will reset all the access counters to zero and clear out all the 'last used' dates.
- Duplicate record check This routine checks for duplicate records and lets you correct them.
|
|
| Database Slack |
|
|
| Figure 13: Managing Database Slack |
|
Dasabase 'slack' is a store of unused objects. It's a good idea to have a number of slack objects available because it's quicker to create new objects from slack than from scratch. How many slack objects should you have? That depends on how many objects you typically create in a session. The default is 30, but you can change this to any number you like. Whatever you set the slack value to, Plato will make sure that you have at least as many as the value you set.
'Slack' is also created whenever you delete an object--the object you delete is not actually deleted, but is rather added to the store of slack objects. Likewise, when you create an new object, that object is 'resurrected' from the slack store and furnished with new data.
If you do not want slack in the database, set the database slack property to zero. This will prevent Plato from adding new slack, and as you add objects to the database the slack will eventually get used up.
Packing the Database
If you want to immediately remove all the slack from a database, you must pack the database. If you have a large database with many slack objects, packing may take several seconds to complete. Packing is a fairly extensive operation and involves rebuilding all the databases internal tables. If the database has a concordance, packing will discard the concordance and you will have to rebuild it from scratch.
|
|
|