Cita:
Empezado por Caral
Hola
No se pero a mi me sobra una tabla.
Saludos
|
No sobra amigo
. Esa tabla que señalas es una tabla intermedia entre Usuarios y Empresas. De no estar presente esta tabla, la relación sería (1:M) y aquí lo que se busca es en realidad (M:M): que un usuario pueda estar en más de una empresa, y que a su vez en una empresa estén muchos (y por tanto, diferentes) usuarios.
Como te han dicho: no está del todo claro la estructura de tus tablas. Por favor no seas tan simplón en tus palabras. Explícate apropiadamente. Cuando más nos puedas decir al respecto más fácil se nos hará comprenderte.
Comprendo bien el uso de las tres primeras que describes, pero las dos restantes no le encuentro forma, uso y unión con el resto. No se aprecia la relación que se busca.
Respondiendo a tus preguntas iniciales:
Cual es la forma correcta de desarrollar esto?
La forma correcta es analizar el negocio o contexto. De dicho análisis surgen las entidades, sus campos y relaciones. No hay receta mágica que indique como llevar el diseño de un DB.
Existe una única forma correcta?
No. Como he dicho: no hay receta, el análisis lo dirá. Incluso en lo que hace al estilo de clave primaria simple vs compuesta; aunque en lo general son pocos los escenarios donde se estilan y se necesitan de claves compuestas.
Cada persona puede tener su propio diseño de una base de datos. Mientras se responda a las necesidades y requisitos estará bien. Habrá quienes "complican" el diseño en un lado para hacerlo más fácil en otro.
Como lo plantearía ustedes?
De las respuesta a 1 y 2 se debería entender que en realidad depende de un análisis del caso y ya cada uno hará su interpretación... no necesariamente todos vamos a coincidir. Cada uno lo podría interpretar diferente. Así como está expresado en tus palabras... hay mucho peligro de que se interprete cualquier cosa respecto a las tablas rendiciones y detrendiciones.
Si te explicas mejor quizá podamos ofrecerte guías, alternativas y sugerencias y podamos llegar a cierto consenso.
Saludos,