update - post firebase

Relación de muchos a muchos en Firebase

Question

Tengo una base de datos de Firebase. Tengo empresas y contratistas. Un contratista puede trabajar para más de una compañía y una empresa puede tener múltiples contratistas. Esta es una relación directa de muchos a muchos. Quiero poder responder las preguntas sobre empresas y contratistas:

1. Dada una empresa, ¿quiénes son los contratistas actuales?
2. Dado a un contratista para qué están trabajando las empresas.

¿Cuáles son las alternativas para estructurar los datos dentro de Firebase?

Answer 1

Después de más investigaciones, voy a tratar de responder mi propia pregunta. He revisado varias otras publicaciones y una solución al problema de muchos a muchos es almacenar una lista de ContractorKeys dentro de un objeto de la Compañía y almacenar una lista de CompanyKeys dentro de cada objeto del contratista. Esto se ilustra con un ejemplo a continuación.

companies : {
companyKey1 : {
name : company1
...
contractors : {
contractorKey1 : true,
contractorKey3 : true
}
}
companyKey2 : {
name : company2
...
contractors : {
contractorKey2 : true,
}
}
}
contrators : {
contractorKey1 : {
name : bill
...
companies : {
companyKey1 : true
}
}
contractorKey2 : {
name : steve
...
companies : {
companyKey1 : true
}
}
contractorKey3 : {
name : jim
...
companies : {
companyKey2 : true
}
}
}

Esta organización "funciona" en el sentido de que las preguntas antes mencionadas pueden ser respondidas. Pero una desventaja de esta solución es que hay dos listas para mantener cuando las asignaciones del Contratista / Compañía cambian. Sería mejor si hubiera una manera de representar esta información en una sola lista.

Creo que he encontrado una mejor solución. La solución es crear una tercera lista, además de compañías y contratistas llamados companyAndContractorAssignment. Los elementos de esta lista representarán una relación entre un solo contratista y la empresa. Su contenido será un par de campos, el contractorKey y la companyKey. Entonces podemos eliminar la lista de contratistas dentro de la empresa y la lista de empresas dentro del contratista. Esta estructura alternativa se representa a continuación. Tenga en cuenta que no hay una lista de contratistas dentro de un objeto de empresa y ninguna lista de empresas con un objeto de contratista.

companies : {
companyKey1 : {
name : company1
...
}
companyKey2 : {
name : company2
...
}
}
contrators : {
contractorKey1 : {
name : bill
...
}
contractorKey2 : {
name : steve
...
}
contractorKey3 : {
name : jim
...
}
}
companyAndContractorsAssignment : {
key1 : {
contractorKey1 : true,
companyKey1: true,
}
key2 : {
contractorKey3 : true,
companyKey1: true,
}
key3 : {
contractorKey2 : true,
companyKey2: true,
}

Esta estructura alternativa le permite a uno responder las preguntas utilizando una consulta orderByChild / equalTo en companyAndContractorsAssignment para encontrar todas las empresas para un contratista o todos los contratistas de una empresa. Y ahora solo hay una lista para mantener. Creo que esta es la mejor solución para mis requerimientos.

Answer 2

La auto-respuesta es de hecho una forma de modelar esto. Probablemente sea el equivalente más directo de cómo lo modelarías en una base de datos relacional:

• contratistas
• compañías
• companyAndContractorsAssignment (la tabla de conectores many-to-many)

Una alternativa sería usar 4 nodos de nivel superior:

• contratistas
• compañías
• companyContractors
• contractorEmpresas

Los dos últimos nodos se verían así:

companyContractors
companyKey1
contractorKey1: true
contractorKey3: true
companyKey2
contractorKey2: true
contractorCompanies
contractorKey1
companyKey1: true
contractorKey2
companyKey2: true
contractorKey3
companyKey1: true

Esta estructura bidireccional le permite buscar "contratistas para una empresa" y "empresas para un contratista", sin que ninguno de estos deba ser una consulta. Esto seguramente será más rápido, especialmente cuando agrega contratistas y compañías.

Si esto es necesario para su aplicación, depende de los casos de uso que necesite, los tamaños de datos que espera y mucho más.

Lectura recomendada Modelado de datos NoSQL y visualización de Firebase para desarrolladores de SQL . Esta pregunta también apareció en un episodio de la serie #AskFirebase de youtube .

Actualización (2017016)

Alguien publicó una pregunta de seguimiento que enlaza aquí sobre la recuperación de los artículos reales de los nodos "contratistas" y "empresas". Tendrá que recuperar esos a la vez, ya que Firebase no tiene un equivalente para SELECT * FROM table WHERE id IN (1,2,3) . Pero esta operación no es tan lenta como puede pensar, porque las solicitudes se canalizan a través de una única conexión. Obtenga más información al respecto aquí: agilice la obtención de publicaciones para mi aplicación de red social mediante el uso de consultas en lugar de observar un único evento repetidamente .