0

I have two forms, Company and Client. A company can have any number of clients, and a client can be a client of any number of companies. I want to be able to do things like list a given company's clients, or list the companies that a given client employs. What is the best way to deal with this using the Domino database structure?

Josh Jolly
  • 11,258
  • 2
  • 39
  • 55
  • What do mean with *things*? There are many ways to skin a cat, and each has its advantages and limitations... Performance? Flexibility? Easy to implement? – Sven Hasselbach Jul 11 '12 at 19:27

2 Answers2

3

That's no problem.

Create categorized views for companies and for clients. Then, store the company names on each client document and client names on each company document. Use a single-category embedded view to list them on each form. Clicking on the name in the embedded view opens the document.

Or, create a third form type for company-client relationships and use that to populate the embedded view.

David Navarre
  • 1,022
  • 10
  • 27
  • 1
    The third "form" option is the way to go if there are lots to lots as Josh suggests. There does not need to be a form, just documents and a view for the UI. We have built something like this for a special needs services organization. Contact me for a demo if interested. -Newbs – Newbs Jul 12 '12 at 17:48
  • @Newbs If there's no separate form, then it's the same solution as the first one (putting company names on client docs and vice-versa). The reason to have the separate document is to allow management of connections without editing the docs on either end. – David Navarre Jul 13 '12 at 01:02
  • 1
    +1 for too many relations it is simplest solution to avoid 64k limit of fields in document. unnecessary saves of master documents is also good point. – Frantisek Kossuth Jul 13 '12 at 10:43
  • @DavidNavarre - I said you did not need a "form" but yes you need a document. Notes allows creation of documents without a form. XPages allows it also. The software Purests do not like it, but it can be done and is very powerful. – Newbs Jul 13 '12 at 12:39
  • @Newbs You're adding a level of abstraction in this case (not creating the form) with little point to it, other than to prove it can be done. You're going out of your way if you create the document for the relationship and only allow the user to modify it through other documents instead of directly. One of the advantages of having a document for the relationship is that you can edit it directly, so why take that away? – David Navarre Jul 13 '12 at 19:34
  • Five years later, I think Henry's solution is better! – David Navarre Jul 18 '17 at 15:22
0

First a question: what's the difference between a Client and a Company? A relation could then simply be represented by a multi-value field ClientOf that stores the keys of one or more other companies. If you want to find all clients of company X, you need a categorized view with the ClientOf field in the first column.

I suppose your problem is not (going to be) so much the creation of the relationship as well the maintenance. You have to maintain everything yourself, i.e. when a company is removed, you have to remove all references to the company yourself, from the ClientOf field. When you use keys created using @Unique, you won't have to worry about a name change of the Company. On the other hand, you always have to do an extra lookup to find its real name.

D.Bugger
  • 2,300
  • 15
  • 19