Conseil de schéma de base de données

Question

Je crée un répertoire d'adhésion pour une organisation et j'essaye de trouver une manière gentille de garder les détails de tout le monde dans l'ordre et la manière updateable. J'ai 3 tables:

table personne gère la personne réelle

CREATE TABLE `person` (
    `personid` BIGINT PRIMARY KEY AUTO_INCREMENT, 
    `personuuid` CHAR(32) NOT NULL, 
    `first_name` VARCHAR(50) DEFAULT '', 
    `middle_name` VARCHAR(50) DEFAULT '', 
    `last_name` VARCHAR(50) DEFAULT '', 
    `prefix` VARCHAR(32) DEFAULT '', 
    `suffix` VARCHAR(32) DEFAULT '', 
    `nickname` VARCHAR(50) DEFAULT '', 
    `username` VARCHAR(32) , 
    `created_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00', 
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000', 
    `last_updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
    `last_updated_by` CHAR(33) DEFAULT '000000000000000000000000000000000' 
) ENGINE=InnoDB, COMMENT='people'; 

Informations sur une personne. Telles que l'école, le numéro de téléphone, l'email, le nom de twitter, etc. Toutes ces valeurs seraient stockées dans «valeur» comme json et mon programme manipulera tout. À chaque mise à jour par l'utilisateur, une nouvelle entrée est créée pour montrer la transition des changements.

CREATE TABLE `person_info` (
    `person_infoid` BIGINT PRIMARY KEY AUTO_INCREMENT, 
    `person_infouuid` CHAR(32) NOT NULL, 
    `person_info_type` INT(4) NOT NULL DEFAULT 9999, 
    `value` TEXT, 
    `created_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00', 
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000', 
    `last_updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
    `last_updated_by` CHAR(33) DEFAULT '000000000000000000000000000000000' 
) ENGINE=InnoDB, COMMENT="Personal Details"; 

Une carte entre la personne et person_info tables

CREATE TABLE `person_info_map` (
    `personuuid` CHAR(32), 
    `person_infouuid` CHAR(32) , 
    `created_on` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000', 
    `is_active` INTEGER(1) 
) ENGINE=InnoDB, COMMENT="Map between person and person info"; 

Donc, étant donné que je suis en train de créer une nouvelle entrée dans person_info chaque fois une mise à jour, je me demande si je devrais vous soucier i/o des erreurs, des tableaux qui deviennent trop gros, etc. Et si oui, quelles sont les solutions possibles? Je n'ai jamais vraiment travaillé avec des schémas de base de données comme celui-ci, donc je me dis que je devrais demander de l'aide plutôt que de me faire baiser dans le futur.

Je suis sûr que certains pourraient demander à quelle fréquence les mises à jour peuvent se produire. Honnêtement, je ne m'attends pas à trop. Nous avons actuellement 2k membres dans notre répertoire et je ne m'attends pas à ce que nous ayons jamais plus de 10k membres actifs à tout moment. Je pense également que nous aurons au plus 50 types d'options différentes, mais pour des raisons de sécurité et d'avenir, j'autorise jusqu'à 1000 types d'options différentes. Compte tenu de ce petit morceau, est-ce que quelqu'un a des conseils sur la façon dont je devrais procéder à partir d'ici?

Answer 1

Donc, personne n'a vraiment répondu à la question, donc je vais poster ce que j'ai fini par faire. Je ne sais pas si cela fonctionnera encore car nos systèmes ne sont pas actifs, mais je pense que cela devrait fonctionner.

Je suis allé de l'avant et j'ai gardé le système que nous avons ci-dessus. J'espère que nous n'atteindrons jamais trop de lignes pour que cela devienne un problème, mais si nous le faisons, je prévois d'archiver une partie des «anciennes» données. Je pense que cela aidera, mais je pense que les machines seront probablement notre rythme d'utilisation.

Answer 2

1. La personne à person_info relation semble comme il devrait être modélisé comme une relation un à plusieurs (i.e. un des dossiers personne a beaucoup de person_info dossiers). Si cela est vrai, le fichier person_info_map peut être supprimé car il ne sert à rien. N'utilisez pas les champs UUID pour établir des relations entre vos tables. Utilisez les clés primaires et créez des contraintes de clé étrangère sur celles-ci. Cela renforcera l'intégrité des données et améliorera les performances des jointures lors de l'interrogation.

Answer 3

j'aurais personnellement les 2 tables fusionnées en vue de la personne au moment actuel, et une autre table où vous écrivez les changements (comme un magasin d'événements).

Cela vous évitera de rejoindre les 2 tables chaque fois que vous devez aller chercher la personne.

Mais c'est maintenant du point de vue de l'application. J'entends déjà le DBA crier dans mes oreilles :)