数据库架构建议答案

【问题标题】：Database schema advice数据库架构建议
【发布时间】：2012-12-28 09:18:25
【问题描述】：

我正在为一个组织创建一个会员目录，并试图找出一种很好的方法来保持每个人的详细信息井井有条且可更新。我有 3 张桌子：

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

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

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 错误、表变大等。如果是这样，有什么可能解决方案？我从来没有真正使用过这样的数据库模式，所以我认为我应该寻求帮助，而不是在未来被搞砸。

我相信有些人可能会问更新的频率。说实话，我并没有期待太多。我们的目录中目前有 2k 个成员，我不希望我们在任何时候都有超过 10k 个活跃成员。我还认为我们最多会有 50 种不同的选项类型，但出于安全和未来的目的，我允许多达 1000 种不同的选项类型。

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

【问题讨论】：

标签： mysql map schema database-schema

【解决方案1】：

person 与 person_info 的关系似乎应该建模为一对多的关系（即一个人记录有许多 person_info 记录）。如果这是真的，可以删除 person_info_map，因为它没有任何作用。
不要使用 UUID 字段来建立表之间的关系。使用主键并在其上创建外键约束。这将强制数据完整性并提高查询时连接的性能。

【讨论】：

这是一个 1-many 地图，但由于 'person' 也可以更新（与 'person_info' 相同的方法，我想要一种简单的方法来知道哪个 personuuid 与哪个 person_infouuid 匹配作为 id两者都会改变。我也不明白拥有 id 而不是 UUID 将如何帮助建立连接。如果个人 a 有 2 条记录，那么我如何（除了 uuid）知道这些是同一个人记录，但是数据改变了吗？

【解决方案2】：

我个人会将 2 个表合并为当前人员的视图，并在另一个表中写入更改（如事件存储）。

这将避免您每次需要取人时都加入 2 个表。

但这是从应用程序的角度来看的。我已经听到 DBA 在我耳边大喊了 :)

【讨论】：

所以您正在考虑将所有内容从 person 转移到 person_info（名称等）？像那样它会把它切成2张桌子吗？ ..但我主要关心的是 person_info 表的大小...你不认为它会爆炸并在它变大时开始出现问题吗？

【解决方案3】：

所以没有人真正回答这个问题，所以我会发布我最终做了什么。我不知道它是否会起作用，因为我们的系统尚未激活，但我认为它应该起作用。

我继续保留我们上面的系统。我希望我们永远不会碰到太多行，这将成为一个问题，但如果我们这样做了，那么我计划归档一大块“旧”数据。我认为这会有所帮助，但我认为机器可能会适应我们的使用速度。

【讨论】：