Pour stocker des personnes dans MySQL (ou n'importe quelle base de données) - plusieurs tables ou une seule table?

Question

Notre société a beaucoup d'entités différentes, mais une bonne partie de ces entités de base de données sont des personnes. Nous avons donc des clients, des employés, des clients potentiels, des entrepreneurs et des fournisseurs, et tous ont certains attributs en commun, à savoir les noms et les numéros de téléphone de contact. J'ai peut-être dépassé la pensée orientée objet, mais maintenant je cherche à créer une table "Person" qui contient toutes les personnes, avec des drapeaux/sous-tables "étendant" ce modèle et ajoutant des attributs basés sur les rôles à la jonction tables si nécessaire. Si nous disions que 250.000 personnes (sur MySQL et ISAM) vont avoir un tel impact sur les performances que les futurs DBA me maudiront pour toujours? Notre recherche la plus commune est sur les combinaisons nom/prénom.

Pour, par exemple. une entreprise comme Salesforce, sont des clients/prospects/employés tous dans une table centralisée avec des sous-vues (à défaut d'un meilleur terme) ou sont-ils séparés dans des tables différentes?

Avertissement: cette question a trait à "nous avons trouvé préférable de faire cela dans le monde réel" par opposition à la conception théorique. J'aime la solution ci-dessus, et je suis confiant qu'avec les vues, le bon dimensionnement et l'indexation précise, cette performance ne souffrira pas. Je pense aussi que ce qui précède ne compte pas comme un MUCK, juste une assez grande table.

Answer 1

Une table « personne » est l'approche la plus flexible, efficace et sans problème.

Il vous sera facile de faire des recherches limitées - trouver toutes les personnes portant ce nom de famille et qui sont des clients, par exemple. Mais vous pouvez également trouver que vous devez rechercher quelqu'un quand vous ne savez pas ce qu'ils sont - ce sera plus facile quand vous avez une table 'personne'.

Cependant, vous devez considérer la possibilité qu'une personne est plusieurs choses à vous - un client parce que acheté un et un entrepreneur parce que vous les avez embauchés pour un travail. Il serait donc préférable d'avoir une table "join" qui vous donne une relation de plusieurs à plusieurs.

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

(Vous voulez ajouter des index et des clés étrangères, bien sûr person_id est une FK à table « personne »;. « Person_type_id » est une FK à votre table de référence pour tous les types de personnes possibles I ». Vous avez ajouté deux champs de date afin que vous puissiez établir quand quelqu'un était ce que vous voulez.)

Answer 2

250.000 enregistrements pour une base de données n'est pas beaucoup. Si vous définissez vos index de manière appropriée, vous ne trouverez jamais de problème avec cela.

Vous devez probablement définir un type pour un utilisateur. Ces types doivent être dans une table différente, de sorte que vous pouvez voir ce que le type signifie (en faire un TINYINT ou similaire). Si vous avez besoin de champs supplémentaires par type d'utilisateur, vous pouvez en effet créer une table différente pour cela.

Cette approche semble vraiment bon pour moi

Answer 3

Puisque vous avez beaucoup de différents « types » de personnes, afin d'avoir la conception normalisée, avec les clés étrangères appropriées, il est préférable d'utiliser le modèle supertype/sous-type. Une table Person (avec le commun à tous les attributs) et plusieurs tables de sous-types (Employee, Contractor, Customer, etc.), toutes en relation 1: 1 avec la table Person principale, et avec les détails nécessaires pour chaque type de personne.

Cocher cette réponse par @Branko pour un exemple: Many-to-Many but sourced from multiple tables

Answer 4

En théorie, il serait possible d'être un client pour l'entreprise que vous travaillez.

Mais si ce n'est pas le cas ici, alors pourrait stocker des personnes dans différentes tables en fonction de leur rôle.

Cependant, comme Topener a dit, 250.000 n'est pas beaucoup. Donc je me sentirais personnellement en sécurité pour stocker chaque personne dans une table.

Et puis ont une colonne pour chaque rôle (employé, client, etc.)

Answer 5

Même si vous finissez avec une solution à une table (pour les attributs de la personne principale), vous allez vouloir l'extraire avec des vues et mettre sur certaines contraintes. La dernière chose que vous voulez faire est d'envoyer des informations confidentielles à des clients qui étaient seulement supposées aller aux employés parce que quelqu'un ne s'est pas joint correctement. Ou une jointure accidentelle qui fait doubler le revenu sur un rapport (mais seulement pour des clients particuliers qui ont aussi un employé lié d'une manière ou d'une autre).

Cela dépend vraiment de la façon dont vous voulez que les couches regardent et quels composants vont accéder aux couches et comment.

Aussi, je pense que vous voulez revoir votre choix de MyISAM sur InnoDB.