Para almacenar personas en MySQL (o cualquier base de datos): ¿varias tablas o solo una?

Question

Nuestra empresa tiene muchas entidades diferentes, pero una buena parte de esas entidades de base de datos son personas. Entonces, tenemos clientes, empleados, clientes potenciales, contratistas y proveedores, y todos ellos tienen ciertos atributos en común, a saber, nombres y números de teléfono de contacto.

Puede haber ido por la borda con el pensamiento orientado a objetos pero ahora estoy buscando hacer una tabla de "Persona" que contenga todas las personas, con banderas/subtablas "extendiendo" ese modelo y agregando atributos basados ​​en roles al cruce tablas según sea necesario. Si llegamos a decir 250,000 personas (en MySQL e ISAM), ¿esto afectará tanto el rendimiento que futuros DBA me maldecirán para siempre? Nuestra búsqueda más común es en combinaciones de nombre/apellido.

Para, p. Ej. una empresa como Salesforce, ¿son Clientes/Clientes/Empleados, todos en una tabla centralizada con sub-vistas (a falta de un mejor término) o están separados en diferentes tablas?

Advertencia: esta pregunta tiene que ver con "nos pareció mejor hacerlo en el mundo real" en comparación con el diseño teórico. Me gusta la solución anterior, y estoy seguro de que con las vistas, el tamaño adecuado y la indexación precisa, ese rendimiento no sufrirá. También siento que lo anterior no cuenta como MUCK, solo una mesa bastante grande.

Answer 1

Una mesa de 'persona' es el enfoque más flexible, eficiente y sin problemas.

Le resultará fácil hacer búsquedas limitadas, buscar a todas las personas con este apellido y que son clientes, por ejemplo. Pero también puede encontrar que tiene que buscar a alguien cuando no sabe cuáles son, lo que será más fácil cuando tenga una mesa de "persona".

Sin embargo, debe tener en cuenta la posibilidad de que una sola persona tenga varias cosas para usted: un cliente porque compró algo y como contratista porque usted las contrató para un trabajo. Sería mejor, por lo tanto, tener una tabla de "unión" que le proporcione una relación de muchos a muchos.

create person_type (
    person_id int unsigned, 
    person_type_id int unsigned, 
    date_started datetime, 
    date_ended datetime, 
    [ ... ] 
) 

(Usted querrá agregar índices y claves externas, por supuesto person_id es una FK a la mesa 'persona'; 'person_type_id' es una FK a su tabla de referencia para todos los posibles tipos de persona I'. He añadido dos campos de fecha para que pueda establecer cuándo alguien fue para usted.

Answer 2

250,000 registros para una base de datos no es mucho. Si configura sus índices de forma adecuada, nunca encontrará ningún problema con eso.

Probablemente deba establecer un tipo para un usuario. Esos tipos deben estar en una tabla diferente, para que pueda ver lo que significa el tipo (que sea TINYINT o similar). Si necesita campos adicionales por tipo de usuario, puede crear una tabla diferente para eso.

Este enfoque suena muy bueno para mí

Answer 3

Puesto que usted tiene muchas diferentes "tipos" de las personas, con el fin de tener el diseño normalizado, con restricciones de clave externa adecuados, es mejor utilizar el patrón supertipo/subtipo. Una tabla Person (con el común a todos los atributos) y muchas tablas de subtipos (Employee, Contractor, Customer, etc.), todas en relación 1: 1 con la tabla Person principal, y con los detalles necesarios para cada tipo de Persona.

Comprobar esta respuesta por @Branko para ver un ejemplo: Many-to-Many but sourced from multiple tables

Answer 4

Teóricamente sería posible ser un cliente de la empresa para la que trabaja.

Pero si ese no es el caso aquí, entonces podría almacenar personas en diferentes tablas, dependiendo de su función.

Sin embargo, como dijo Topener, 250.000 no es mucho. Así que personalmente me sentiría seguro para almacenar a cada persona en una sola mesa.

y luego tener una columna para cada rol (empleados, clientes, etc.)

Answer 5

Incluso si termina con una solución de una sola tabla (para los atributos de persona central), va a querer abstraerla con vistas y ponerla en algunas restricciones.

Lo último que desea hacer es enviar información confidencial a los clientes que se suponía que debía ir a los empleados porque alguien no se había unido correctamente. O una combinación cruzada accidental que hace que los ingresos se dupliquen en un informe (pero solo para clientes particulares que también tenían un empleado vinculado de alguna manera).

Realmente depende de cómo quiera que se vean las capas y qué componentes van a acceder a qué capas y cómo.

Además, creo que desea volver a visitar su elección de MyISAM sobre InnoDB.