Question

I have recently started to work with RavenDB.

Here’s a traditional example in relational db:

EmployeeType

ID:1 TYPE:DEV
ID:2 TYPE:QA

Employee

NAME:FRED TYPEID:1
NAME:JACK TYPEID:2

From what I understand of RavenDB the type would be included with the employee:

Employee

NAME:FRED TYPE:DEV
NAME:JACK TYPE:QA

Would there then be a need for the EmployeeType table?

If not, if you were to display a drop down list of employee type, would you just select distinct(Type) from Employee?

If you were to do the above, how would you add a new employee type, without entering a new employee (or editing an existing one)? Or would you just keep a list in code somewhere?

And lastly, if the text for an employee type were changed, it seems like you would then need to update all the employee records. What if there are 100,000 employee records?

I’m new to Raven (document databases), so any insight to help me better grasp the different paradigm would be appreciated.

Answer 1

Would there then be a need for the EmployeeType table?

There would be to fulfill requirements of the next question. Also, this type of reference data could just be stored in a single document, not a document collection. You may also maintain a hard-coded list, bypassing a database all together.

If not, if you were to display a drop down list of employee type,
would you just select distinct(Type) from Employee?

No. Select from an employee types document. Selecting distinct from an employees tables would tell you the types of employees on record, not the available employee types.

And lastly, if the text for an employee type were changed, it seems
like you would then need to update all the employee records. What if
there are 100,000 employee records?

You’re facing what is effectively a trade-off between relational databases and document databases. You have a few options. You can reference employee types from employee documents by an ID which points to an employee type document collection. In this way, you can change the employee type name in one place. However, the trade-off is that RavenDB will need to include (join) that two documents to return an employee with a type. The alternative is to avoid an employee type ID and store the type directly in the employee document and when names need to be change you would run an update across all documents. Take a look here from the RavenDB docs.