IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Say you have a project database design -- one database per project -- and you want to be able to navigate around groups of related ones nicely. This is a question that came up recently in the 6/7 forum. The developer in that case was trying to figure out how to combine the databases into a single database and show only one project's worth of data at a time.

You can do that sort of thing using @SetViewInfo, but my suggestion in this case was to leave them as separate databases and try to find ways to fulfill whatever other requirements might involve treating all the databases as a unit.

The two most probable such requirements are (1) that users be able to find their way around among the different projects, and (2) that management be able to get reports based on all the project data. Managers like reports, in much the way my old aunt likes tea -- it warms their hearts and gives them a sense of security.

Of course, a report doesn't have to be a view -- it's not hard to generate reports on the fly from data in multiple databases, either using Notes and rich text (e.g. with the ReportGenerator class I posted), or outside reporting tools, or if you must have a view, you could always create a digest database. Or, using NSFDB2, you could bring live data in from all the databases on the fly.

So that the users can navigate around the multiple databases, all that's really needed is a control in the navigation area. So this might be links in an outline, or it might be a combobox with Onchange code to close the current database and switch to the selected database. When a database is added or deleted, this control could either be maintained in the template from which all the databases inherit (if all copies of the design should show the same set of other databases) or via a profile document (if there are distinct sets of databases which reference each other, or if you prefer). Updating this profile should reach out to the other databases you list there and update their profiles also, so that there's a consistent list as you navigate around. The information stored for each database should include the database name, server "hint", replica ID, and optionally a list of readers, in case the link shouldn't show up for all users.

That's just my rambling thoughts. What do you folks do in situations like that?

Andre Guirard | 30 January 2008 08:30:00 AM ET | Man-Cave, Plymouth, MN, USA | Comments (1)


 Comments

1) My typical technique
Andy Broyles | 1/30/2008 10:22:12 AM

I tend to use a collection database as a front end to the distinct project databases.

In the collection database I store documents that have readernames and descriptions of the projects, repids, and server/path/file fields, project manager, department, etc.

I put those documents into two basic types of views, one for general consumption, and another for administrative use.

In the general consumption views, I have a queryopendocument event that instead of opening the document, opens the database it represents. I then also code action buttons for reporting that include a prompt for which projects to include in the report 'Selected' (those documents which are selected in the view) or 'All' and then uses techniques like you use in the ReportGenerator to create 'reports'.

I generally use and outline and multiple views with different categorization schemes to allow users to find and navigate the projects to their liking.

The admin view doesn't have the view queryopendocument event code and allows for db manasger control over the documents.

Depending on the use case, I have included code in the project database template that causes a newly created project database to create its own reference document in the collection database. In other cases, I have had an agent which periodically scans directories and addes the databases...really depends on the need.

I also use a nightly agent to manage the reference documents...insure the target dbs exist, update readers fields and database biographics, etc.

2) Ummmmm...
Nathan T. Freeman | 1/30/2008 12:18:03 PM

I use this handy tool called a "frameset." :-D

3) re: Ummmmm...
Andre Guirard | 1/30/2008 2:43:48 PM

I did intend for this to be used in the context of a frameset, but I'm assuming that each database in the set that you want to appear as if it's a single application, also has its own set of views. That means when you select a different database, you can't just change the contents of one frame -- the views listed in the navigation area must now point to the new database.

I suppose you could have one frame used for navigating among databases, and one frame that displays a frameset in the target application which includes navigation within the application. But the point remains that if you follow a doclink then ask to open the application containing that document, you want to see the whole list of other databases in each of them.

4) Great Subject
Alex K | 2/4/2008 4:20:18 AM

I am fighting with this "Problem" for a while now. Trying to connect several knowledge-base databases through a signle interface, my biggest problem is searching and getting the results nicely visible.

For the moment I use the Search site template, but I dont get it to deliver results as I expect.

I am very curious what people come up with when presented this problem.

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact