mysql - 数据库架构建议

Question

我正在为一个组织创建一个成员(member)目录，并且我正在尝试找到一种好方法来保持每个人的详细信息有序且可更新。我有 3 张 table :

Person 表处理实际的人

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';

关于一个人的信息。例如学校、电话号码、电子邮件、twitter 名称等。所有这些值都将以 json 形式存储在“value”中，我的程序将处理所有内容。用户每次更新时都会创建一个新条目来显示更改的过渡。

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";

person 和 person_info 表之间的映射

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";

因此，考虑到每次有更新时我都会在 person_info 中创建一个新条目，我想知道我是否应该担心 I/O 错误、表变大等问题。如果那么，可能的解决方案有哪些？我从来没有真正使用过这样的数据库模式，所以我认为我应该寻求帮助，而不是在将来被搞砸。

我确信有些人可能会问更新的频率是多少。说实话我并没有抱太大期望。目前，我们的目录中有 2,000 名成员(member)，我不希望我们在任何时候都拥有超过 10,000 名活跃成员(member)。我还认为我们最多有 50 种不同的选项类型，但出于安全和 future 的目的，我允许最多 1000 种不同的选项类型。

考虑到这一点，有人对我应该如何从这里开始有任何建议吗？

Answer 1

1. person 到 person_info 的关系似乎应该被建模为一对多关系(即一个人记录有许多 person_info 记录)。如果这是真的，则可以删除 person_info_map，因为它没有任何作用。

2. 不要使用 UUID 字段来建立表之间的关系。使用主键并对其创建外键约束。这将加强数据完整性并提高查询时联接的性能。