%3F.png)
Siempre es fácil escribir software que maneje una sola entidad. Sin embargo, diseñar software para manejar múltiples cuentas/empresas requiere la debida diligencia.
Actualmente estoy haciendo una investigación inicial sobre esquemas de bases de datos que manejan múltiples cuentas/compañías, y les pregunto si pueden compartir una página web o un software de código abierto que demuestre el esquema adecuado.
Editar:Pude encontrar la terminología adecuada para esto, que es Arquitectura de datos multiinquilino. Un útil artículo de Microsoft que describe el enfoque:http://msdn.microsoft.com/en-us/library/aa479086.aspx
Gracias.
Respuesta1
Esto es sólo un poco más complicado que una "entidad única". Supongamos el peor de los casos: varias empresas, cada una con varias cuentas. Una mesa para empresas. Una tabla para cuentas con una clave externa del ID de la empresa. Luego, cada transacción tiene la clave externa del ID de cuenta. Para todos los demás datos, debe decidir si pertenecen a una empresa, una cuenta o alguna otra. Es decir, los empleados sólo pueden trabajar para una empresa (en términos generales), por lo que el empleado tiene el ID de la empresa como clave externa. Una División estaría en una empresa, misma relación.
Se trata de entender qué pertenece a quién y establecer la relación. Esto puede parecer tremendamente simplista, pero en realidad eso es todo.
Buscar utilizar algún esquema establecido puede ahorrarle mucho esfuerzo, pero ese esfuerzo es lo que asegura un buen resultado. Un buen diseño de base de datos surge de hacer TODAS las preguntas: "¿Puede un empleado trabajar para más de una división?" "¿Las compras siempre se cargan a un departamento o se puede repartir el coste?" "¿Necesitamos realizar un seguimiento de más de una aprobación para la reasignación de un empleado?" Esto continúa para siempre, pero si no lo hace, su sistema decepcionará constantemente a los usuarios y requerirá modificaciones interminables.