Question

我正在为一个组织创建一个成员资格目录，而我正试图想出一个很好的方法来按顺序和可更新的方式保存每个人的详细信息。我有3张桌子：

人员表处理实际的人

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

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

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

Answer 1

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

Answer 2

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

这样可以避免每次需要抓取此人时加入2个表格。

但现在从应用程序的角度来看。我听说DBA在我耳边喊道：）

Answer 3

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

我继续保持上面的系统。我希望我们不会打太多行，这会成为一个问题，但如果我们这样做，那么我计划归档一大堆“旧”数据。我认为这会有所帮助，但我认为机器的使用速度可能很快。

数据库架构建议

3 个答案: