Best way of approaching database design

HCL Domino Domino Forum
1

Hi all,

I am creating a database to manage workshops, along the following lines:

A workshop form with details such as Workshop Name, Date, No, Location etc.

A contact nomination form with details such as Contact Name, Workshop nominated for, Nominating person etc.

A contact cancellation form for canceling a contact’s nomination.

Workshop document creation will be restricted.

Anyone can create a contact and nominate them to a particular workshop.

Anyone can cancel a contact’s nomination.

Entering a workshop document will show the workshop details plus all contacts nominated for that workshop, plus any contacts canceled from nomination, so an audit trail really.

My main design question is what is the best approach to linking the workshop document with relevant contact nomination documents?

A hidden field with the workshop document unique identifier?

As an audit trail is required then I think the workshop document needs to be updated at the time of nomination or cancellation. Would this work best as a table on the workshop document with hidden rows?

If I need to build a list of all the contact nominations for a particular workshop, would using the FTSearch method through all contact nomination documents on the unique ID work best?

What would be the best way of showing available meetings that a contact can be nominated for - @DBLookup or @Picklist on a workshop view?

Finally, I’ll need to keep them in sync, so that when the meeting description changes for example, the nomination documents will display the correct list of meeting names. A script when the workshop document changes / scheduled agent perhaps?

Any input provided is appreciated.

Many thanks,

2

Subject: Re: Best way of approaching database design

My main design question is what is the best approach to linking the workshop document with relevant contact nomination documents?A hidden field with the workshop document unique identifier?

Answer = One of the best way to link a document to a number of documents is to make them parent and child. You can make your Workshop document as parent document and your contact nomination or contact cancel as reponse document. You don’t need a unique identifier if you use this technique

As an audit trail is required then I think the workshop document needs to be updated at the time of nomination or cancellation. Would this work best as a table on the workshop document with hidden rows?

Answer = Its not effective to store boundless rows of informaion in a table since rows in a table is only limited and its so difficult to put hidden formula in each rows. Unless you will only consider a number of rows is needed, else you better use Rich Text field and all you have to do is append text everytime an update is triggered.

If I need to build a list of all the contact nominations for a particular workshop, would using the FTSearch method through all contact nomination documents on the unique ID work best?

Answer = If you will use the Parent - Child I suggest in your first question then it is not hard to track down the nomination documents of your worksshop. Just use the parentdoc.Responses and you have it all.

What would be the best way of showing available meetings that a contact can be nominated for - @DBLookup or @Picklist on a workshop view?

Answer = Depends on your source and the way you prompt the user and the way you want to get the answer. But basically if you want and object type of answer then Picklist is prefered.

3

Subject: Design question

Late reply I know…Anyway thanks for your detailed responses.

I haven’t used the Parent / Child facility in Notes at all. If I search the help documentation I assume that this will give me more information (don’t have access to the documentation at the moment)? I get the idea behind it though.

Is the Parent / child facility different from the Main document / Response document facility?

Thanks,