0

我正在为一个组织创建一个会员目录，并试图找出一种很好的方法来保持每个人的详细信息井井有条且可更新。我有 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 存储在“值”中，我的程序将处理所有内容。在用户每次更新时，都会创建一个新条目以显示更改的转换。

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 种不同的期权类型。

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

4

3 回答 3

1

  1. person 与 person_info 的关系似乎应该建模为一对多的关系（即一个人记录有许多 person_info 记录）。如果这是真的，那么 person_info_map 可以被删除，因为它没有任何用处。

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

于 2012-12-15T14:59:05.873 回答
0

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

这样可以避免您每次需要取人时都加入 2 张桌子。

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

于 2012-12-15T14:59:18.620 回答
0

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

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

于 2012-12-28T01:18:25.167 回答