as bases de datos orientadas a @Document (particularmente RavenDB) realmente me intrigan, y quiero jugar un poco con ellas. Sin embargo, como alguien que está muy acostumbrado al mapeo relacional, estaba tratando de pensar cómo modelar datos correctamente en una base de datos de documentos.

Digo que tengo un CRM con las siguientes entidades en mi aplicación C # (dejando de lado las propiedades innecesarias):

public class Company
{
    public int Id { get; set; }
    public IList<Contact> Contacts { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Contact
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Task
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public Contact Contact { get; set; }
}

staba pensando en poner todo esto en unCompany document, ya que los contactos y las tareas no tienen un propósito fuera de las empresas, y la mayoría de las veces la consulta de una tarea o contactos también mostrará información sobre la empresa asociada.

El problema viene conTask entidades. Digamos que el negocio requiere que una tarea SIEMPRE esté asociada con una empresa, pero opcionalmente también está asociada con una tarea.

n un modelo relacional, esto es fácil, ya que solo tiene unTasks mesa y tener elCompany.Tasks se relacionan con todas las tareas de la empresa, mientras queContact.Tasks solo muestra las tareas para la tarea específica.

Para modelar esto en una base de datos de documentos, pensé en las siguientes tres ideas:

Model Tasks como un documento separado. Esto parece una especie de base de datos anti-documento, ya que la mayoría de las veces que miras a una empresa o contacto, querrás ver la lista de tareas, por lo que tendrás que realizar muchas uniones sobre documentos.

Mantenga tareas que no estén asociadas con un contacto en elCompany.Tasks lista y coloca las tareas asociadas con un contacto en la lista para cada contacto individual. Desafortunadamente, esto significa que si desea ver todas las tareas de una empresa (lo que probablemente sea mucho), debe combinar todas las tareas de la empresa con todas las tareas para cada contacto individual. También veo que esto es complicado cuando desea desvincular una tarea de un contacto, ya que debe moverla del contacto a la empresa

Mantenga todas las tareas en elCompany.Tasks list, y cada contacto tiene una lista de valores de identificación para las tareas a las que está asociado. Esto parece un buen enfoque, excepto por tener que tomar manualmente los valores de identificación y tener que hacer una sublista deTask entidades para un contacto.

Cuál es la forma recomendada de modelar estos datos en una base de datos orientada a documentos?