I am creating a new database for Purchasing items in which the Main ORDER form will have a variable number of items that can be ordered.
I can use Response docs for each item. Or use a Main doc for the Item that has a link back to the Order doc (which also is a main doc).
I vaguely remember there are advantages and disadvantages to both approaches. If I might draw on the experience of experts in this forum, would you list any pros or cons using Response docs in this scenario.
I have taught Notes Programming for 18 years and still don’t have a really good answer to this question- but, in my own programming rarely use doc/response doc method UNLESS it is a discussion (threaded) DB. Just always programmactically bring in the parent document UNID to the children docs and you will be fine.Tom
One of the advantages of joining main documents together with a common reference (e.g. order ref) rather than a response hierarchy, is that if anything goes pear-shaped in the main DB resulting in a parent doc being copied and pasted from another copy of the database, the links to its children remain intact. If the children were connected in a response doc hierarchy, the links would be broken due to the new doc ID.
Tim, that is why the question is difficult to answer- you can have a parent/child relationship w/ out having doc/response/response to reponse doc- you can have orphans in both, though they are harder to find in the latter. In View’s, Notes/Domino handles lining the children up under the parent, where as when you have to “doc” level docs, you have to write the code for same. A response doc must be highlighting a parent in order to be made- but you can control the same behavior w/ Doc level docs. My rule of thumb is only to use response/response to response w/ threaded discussion uses- would love to hear others comments. Tom
I tend to use all docs rather than doc/response designs.
However, if you opt for a doc/response design, there are some things that are ‘built in’ for you.
You can update a parent from a child without the need to do any fancy lookups or build doc collections.
If you need to push data from a parent into all the children, using a recursive LS routine that grabs all siblings of a document may be easier than doing the doc collection with a shared key (or not, it’s probably 6 of one, 1/2 dozen of the other).
I find that the twistie concept with doc/response designs is confusing. If you’re doing a non-hierarchical view, double clicking the item with a twisty, opens the twistie. If you do the same in a doc/response view, you open the document. If need to see children of a parent, you need to click the twistie, not the doc. If you have a mix of doc/doc and doc/response designs, it tends to be confusing which is why I mostly do doc/doc designs.
Like you, I’d love to know if there was some really good place to use doc/response designs.
I am just finishing up an order system with a variable number of lines in the order. I started out by making each line item a separate document containing the Parent ID. I then added a single category embedded view in the Order document to display all the lines in the order. I ran into to many problems with manipulating the items. The embedded view does not handle the selection margin the way I would want it and found it to be to confusing. So I created a subform that controls the entry of each line item and then I place the necessary values in a series of associated Multi-value arrays. I display these arrays in a table on the Order (actually generate an invoice). Once the order has been processed and shipped I then run a process that generates a line item document for each line, plus a Back Order item where necessary. Each Line Item document contains the original Order Number and the Parent ID. I can not slice and dice the orders to generate some pretty nice sales analysis reports.I just found that while using the Arrays requires a bit more programming to have it work smoothly I have total control over the the look and action. Then generate line item documents (not response documents) for each item after we are through with the operator input.
I really don’t like using response documents unless it is a discussion type database. I have also used them in a sort of contact management DB I put together and they worked well there. I guess I’m a bit of a control freak and I really prefer to have total control over what is going on, and too often I found that I could get the function I needed but I could not get the user experience that I wanted.
I know of an ordering system where both main order document, and order line documents all are normal Notes documents. ie, the Response document feature is not used. Main order document, and all order line documents have a field OrderID for which they have same value. Grouping is done based on OrderID field.
Domino may be giving you some kind of benefits in UI and computation, if you use Main-Reponse feature. But this is not a must for Ordering application.
I concur generally with all of the comments made heretofore, and will add my two cents. It depends on the requirement. If you can determine now that you would never need more than x number of line items (with x hopefully being a number less than 10 or 15 or so), and you have no need to integrate with external applications, then perhaps one doc is your best bet. It would certainly be the easiest to create and maintain. However, you CAN create a relational design in Notes. We have a Time and Expense system which receives each month a feed of hundreds of line items from the credit card company on behalf of our employees. This flows into our T&E which programatically creates responses for that individual’s timesheet. They go into the parent, and from an embedded view, go down the list accepting, notating, and approving each line item. They need never open the response. They submit and the submission propogates to the line items for import into our accounting system. Very cool. BUT - there is alot of work involved in coding the referential integrity just so (you have to create it), and the record count in the database gets high very fast. If you would like to learn more, I recommend the Lotus Notes and Domino 6 Programming Bible, by Benz and Oliver. In fact, I think they have an example of a line order entry system using responses as you have requested.