mysql - usar - Base de datos: ¿qué diseño apuntar a dos posibilidades?
seleccionar base de datos mysql (3)
Es difícil dar una respuesta a esto, pero tendría algunas notas que podrían serle útiles.
Pero son solo algunas notas realmente.
En general, este modelo de datos parece estar bien dado lo que se conoce.
- El tipo de actor no necesariamente tiene que ser otra tabla. Podría ser simplemente un valor codificado en esta tabla, por ejemplo.
- Como se señaló en otros comentarios, la tabla de tipos de actores no es técnicamente necesaria si el actor solo puede señalar las dos cosas, pero probablemente todavía la use, ya que es más fácil de mantener y más legible a largo plazo para los futuros mantenedores de el código / sql / base de datos. es decir, la presencia del campo para indicar el tipo agrega valor en la legibilidad humana del código / sql y el modelo, incluso si la máquina no lo necesita.
- Pensando en la evolución de la base de datos, una cosa a considerar, ¿crees que siempre será solo persona / empresa o que en el futuro habrá diferentes tipos? Si es probable que sean tipos de actor adicionales en el futuro, vale la pena considerar ahora si factorizar el actor_type y el ID a una tabla de enlace podría ser útil para limitar la evolución del esquema para esta tabla.
Estoy diseñando un modelo de datos para un nuevo proyecto.
Uno de los requisitos especifica que algunos objetos pueden apuntar a una persona o a una empresa.
¿Cuál es la forma más inteligente de lograr eso?
He pensado en un enlace de tabla "actor" como este (dibujado con el excelente yUML.me BTW):
En la tabla actor , de acuerdo con actor_type , person_id o company_id es una clave externa en su tabla correspondiente o es NULL . De esta forma, cuando one_table desea obtener detalles sobre el actor , empiezo por verificar el campo actor_type y recuperar ya sea person_id o company_id .
Está funcionando, pero estoy buscando un mejor diseño. Aquí está el enlace para editar el diagrama
Sugiero que cree subtipos de compañía y persona que hagan referencia al mismo supertipo (actor). Tenga en cuenta que no necesita person_id, company_id por separado porque un actor debe ser uno u otro y no puede ser ambos. Me gusta esto:
Este es un caso clásico de clases / subclases (o, si prefiere tipos / subtipos). Te sugiero que visites las siguientes tres etiquetas y revises tanto las preguntas etiquetadas como la wiki de etiquetas que puedes ver en "aprender más".
herencia de tabla única herencia de tabla- clase clave primaria compartida
Esto puede darle todas las respuestas que necesita. O puede preferir agregar una o más de estas etiquetas a su pregunta, a fin de atraer más respuestas.
Nota: el motivo por el que se utiliza la palabra "herencia" en las etiquetas es que estas técnicas le permiten obtener algunos de los beneficios que se crean en los entornos de objetos que implementan la herencia.