Containers: databases, groups, and folders

Razor provides significant flexibility on organizing, processing, and viewing your data. It is not for us to say how you should organize your data. We offer this brief discussion of the three basic types of "containers" employed by Razor as food for thought when you are configuring your database. The three containers of information within Razor are: databases, groups, and folders. Here is a picture to get us started...

Databases

A database is a collection¹ of information related by a common theme. There is no association, in the Razor sense, from one database to another. Company projects or products would typically be maintained in separate databases. Each database generally has a team of people, like a project or product team, accessing it.² Keep in mind that there is a separate Razor server for each database, so databases are brought up, managed, accessed, and brought down independently.

Here are some considerations with respect to separating data into different databases:

• Databases are easy to create.
• There is minimal overhead to have multiple databases.
• The smaller the database, the less time it will take for the server to come up.
• Global controls (e.g. access lists, user roles, etc.) are implemented at the database level. There are no Razor-level controls that span databases.
• Databases are "owned" by a single user. That user is the only one who requires read/write access to the database. All client database access is performed by the database server.

Groups

A group is a "narrower" collection, contained within a database. There are issues groups and file control groups. File control groups support versions (on a file-by-file basis) and threads³ (a specific version of each file for a product or project release). Each group has unique and distinct attributes. Groups can have their own set of controls, or can be controlled at the database level.

Issues groups are used to track virtually any information that has a status which changes over time. Issues from one group can not easily be related to issues in another group. Issues can be related to activity within any of the file control groups. For example, issues containing product change requests can be related to file change history for that product as well as related documentation.

File control groups are independent of each other but operations on files can be related to issues. Projects exist within a project group and are composed of threads from one or more thread groups. There is one and only one project group per database, but there is a thread group for every file control group in the database.

To discuss relationships among groups consider an organization that has three different divisions: Development, Support, and Sales. Examples of groups could be:.




Note that the use of some issues groups may overlap with the different organizations. There might be a separate file control group for each product of a family of products, e.g. Word Processor, Spread Sheet, Presentation Manager. Conversely, these products might be included in a single file control group if there is a lot of commonality between them.

Let's see how issues groups can be used to relate activity to file control groups with the above simple example. On the issues side, the development team conduct regular peer reviews during the course of the design and implementation. Development test logs are initially generated by developers and then verified by the support team. All three groups contribute to issues relating to the products development - with sales suggesting feature requests received from customers, support identifying problems, and development inputting both enhancements and problem reports. Sales staff take customer orders for products. Action items from meetings can be tracked across the development and sales teams.

Each division has responsibility for various file control groups - some shared responsibility and some sole responsibility. Development is solely responsible for the source code of their product. Developers may generate their own test data that is then used or augmented by support. Support may also, with inputs from the development team, be responsible for product documentation - both hard copy and Web-based information. Sales contributes to Web pages as a marketing function, but also maintain their own sales literature.

Here are some considerations with respect to separating data into different groups:

• Groups are easy to create.
• There is no overhead for multiple groups.
• Each group has a different set of attributes.
• Groups can override controls implemented at the database level.
• Switching between groups provides a completely new view of the data.

Folders

Folders are the simplest collection. They contain files and are a way of grouping related files. Only file control groups can contain folders. With few exceptions, the folder hierarchy you use in Razor will mirror the directory layout on disk.

Here are some considerations with respect to separating data into different folders:

• Folders are easy to create, and can be done without restarting the database server.
• Folders only apply to file control groups.
• There is no overhead for folders.
• Folders organize logically related files, e.g. libraries.
• Folders can be moved or renamed.
• File names, including their containing folders, must be unique in Razor.
• Folders can contain files and other folders.
• Folder hierarchies are honored when files are extracted with the versions and threads tools (but can be overridden).

¹ We intentionally leave the term "collection" undefined. You can define it appropriately for your application.
² People can access more than one database, but information is not shared between them.
³ See "Themes and concepts" on page 123 for a discussion on threads.