This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


~Autumn Kigeroburakoi
May 25, 2013, 12:22 AM
4 Posts

Document database, how to design and relations?

  • Category: Domino Designer
  • Platform: Windows
  • Release: 9.0
  • Role: Developer
  • Tags: design,relations
  • Replies: 2

A question about design of document database with Domino. What is a correct approach if I take this example:

- It is a university with 5000 COURSES and every course has about 30 fields with data between 5 to 500 characters.

- Every semester these courses repeats which we call it COURSE_ROUND with start date and end date, teachers for the course e t c... A COURSE_ROUND could have arond 20 fields. Bearing in mind COURSE_ROUND is for every semester if in one year we have 2 semesters, 5000 COURSES would create 10 000 COURSE_ROUNDS every year. After 10 years it would be 100 000 COURSE_ROUNDS.

In a relational database would be easy. A table for COURSE and a table for COURSE_ROUND and the course_code wih create a relation between them. But how would you design a Domino document database?

1- Creating a single database and having all courses and course rounds in the same database?
This option would create a single database containing 5000 COURSE documents one time, and 5000 COURSE_ROUND added each semester... 1st semester 10 000 documents, 2nd semester 15 000, and after 10 years 105 000 documents.

2- Creating a database for all courses and another database for all course rounds?
This option would create two databases, one containing 5000 COURSE documents and would not change.  Another one COURSE_ROUND with 100 000 documents in 10 years.

3- Creating a database for a course with all its course rounds in a single database? 
This option would create 5000 databases once. Each semester a single COURSE_ROUND document would be added to every database. After 10 yeare it would still be 5000 databases but every database would contain totally 21 documents, a single COURSE document and 20 belonging COURSE_ROUND documents. 

And one more question... how would I create a relation between a course and its course rounds? In the last option with a course and all its course rounds in a single database would be easy, but all courses are in a database and all course rounds in another database? Maybe the course code as a key, but is there convesion or a correct way to this?

Many thanks if put some lights on my confusion around Domino document database.

~Tanita Zeklutexakol
May 31, 2013, 3:33 PM
32 Posts
I posted your question to another forum
where there are a lot of very knowledgeable Domino developers. One of them responded back thusly:
"Has anyone done something like this that can offer help?"

Stored non-messaging data in an NSF? Sure I've done that a lot!

"Or are they trying to do something must better suited to a different datastore ?"

Well, far more important than the number of records and how much data is in them is: how do they intend to query them? Storing 5000 course rounds every six months is pretty trivial -- you could probably store that by hand on paper. But if you wanted to, say, find all the courses where at least 10 students had also had at least 2 courses together before, then things get a lot more complicated.

There's nothing inherent to NSF that makes it good or bad for the volume of data being talked about. I regularly put tens of millions of documents into NSFs without performance problems. It's when you want to index them that things get problematic. NSF is fast, especially in the context XPages where the data is almost always local to the application controller.

It's NIF that's slow. And it's only slow when it's out of date. If your data is non-volatile, then even if you have indexes with millions of rows displayed, real-world performance is fine as long as that data is static.

It sounds like the scenario is 5000 new documents all at once every six months. That's a pretty trivial amount of update traffic. As long as they avoid standard design pitfalls like time-based views or needless document updates, then the volume actually being discussed makes the storage design irrelevant.

If I were building this, I'd probably put the courses in one NSF and the course rounds in a different NSF, just so I could more easily archive the course round data. (Why would you keep a 10-year history in the live app anyway? "Oh look, History of Latin American Literature was taught by Prof. Moriarty on Tuesday MORNINGS in Spring of 2004! No wonder Holmes couldn't find him!") But that's really just a personal preference and will have zero impact on real-world performance.

--Steve
~Judy Ektumizenynds
Jun 11, 2013, 3:26 PM
30 Posts
Trivially easy in Notes

Multiple options

Use a keyfield to link the course_rounds with the courses

Make the course_rounds children of the courses

Use the course uniqueid as the keyfield for a course round

The data design for this is a five-line solution

Contact me on christopher@meeples.co.uk if you want me to do the work for you


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal