数据库架构建议

我正在为一个组织创建一个会员目录，并试图找出一种很好的方法来保持每个人的详细信息的顺序和可更新的方式。我有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';

关于一个人的信息。例如学校，电话号码，电子邮件，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_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种不同的选项类型。

考虑到这一小块，有没有人有任何意见，我应该如何从这里出发？

来源

2012-12-15 Aram Papazian

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

我继续前进，并保持我们上面的系统。我希望我们不会碰到太多的行，这将成为一个问题，但如果我们这样做，那么我计划归档大量的“旧”数据。我认为这会有所帮助，但我认为机器可能会使用我们的步伐。

来源

2012-12-28 01:18:25

person to person关系的人好像应该建模为一对多关系（即一个人的记录有很多person_info记录）。如果这是真的，可以放弃person_info_map，因为它没有任何用处。
请勿使用UUID字段在表格之间建立关系。使用主键并在其上创建外键约束。这将强制数据完整性并在查询时提高连接的性能。

来源

2012-12-15 14:59:05

这是一张多地图，但由于'人'也可以更新（与'person_info'相同的方法，我想要一个简单的方法来知道哪个personuuid与哪个person_infouuid相匹配，因为这两个人的ID都会变化。我也不明白如何使用id而不是UUID来建立连接。如果person a亲自有2条记录，那么我是如何知道这些是同一个人的记录，但是数据发生了变化？ –

我个人有两个表合并为个人的当前时刻的观点，并有另一个表，其中你写的变化（如事件存储）。

这样可以避免您每次需要取人时加入2张表格。

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

来源

2012-12-15 14:59:18

所以你在考虑把一切从人转移到person_info（名字也是这样）？就像它会将它切成2个表格？..但我主要关心的是person_info表的大小......你不觉得当它变大时会发生爆炸并开始出现问题？ –

数据库架构建议

回答

相关问题