在这种情况下，GUID 是地址的良好参考键吗？

Question

我目前正在从事建筑管理软件工作，在为我的数据库设计架构时遇到了一个问题（如下所述），目前我的数据库包含四个表，即 employee、地址、用户和许可证。

造成混淆的表格是employee和address； 下面提供的代码。

为了维护我的数据的Physical integrity，我没有存储任何从address词法派生的东西，例如Address1、Address2、City、State、County表员工中的等；因为我主观地认为，将不能唯一标识特定员工的属性作为另一个表的一部分会更好。现在我的问题出现了：

• GUID 作为 address 表的主键是不是一个不错的选择？
• 如果是，是否有可能是阻碍快速查询的因素？

我选择使用 GUID 作为 PK 索引的原因是我别无选择。 EmployeeId 来自 address 并没有为我提供解决方案，因为我不能拥有一个 PK 和 FK 的字段：see this。 p>

CREATE TABLE employee(

    employeeId  INT
                NOT NULL
                CHECK(employeeId > 0),

    firstname   VARCHAR(20) 
                NOT NULL,

    lastname    VARCHAR(20)
                NOT NULL,

    sex         VARCHAR(1)
                NOT NULL,

    birthdate   DATE
                NOT NULL,

    addressId     VARCHAR(30),

    PRIMARY KEY(employeeId)
);

CREATE TABLE address(
    addressId   VARCHAR(30)
                NOT NULL,

    employeeId  INT,

    Address1    VARCHAR(120)
                NOT NULL,

    Address2    VARCHAR(120),

    Address3    VARCHAR(120),

    City        VARCHAR(100)
                NOT NULL,

    State       CHAR(2)
                NOT NULL,

    Country     CHAR(2)
                NOT NULL,

    PostalCode  VARCHAR(16)
               NOT NULL,

    PRIMARY KEY(addressId),

    FOREIGN KEY(employeeId) REFERENCES employee(employeeId) ON DELETE SET NULL

);

ALTER TABLE employee
ADD FOREIGN KEY(addressId)
REFERENCES address(addressId)
ON DELETE SET NULL;

我很想知道是否有任何其他方法可以在不使用 GUID 的情况下在 employee 和 address 之间建立适当的关系。另一种方法是指定 (int) 值，但在这种情况下，缺点是：

• 错误地引入了 FK != PK，这将导致表之间的关系不佳。

编辑：

你们中的一些人在 cmets 中建议将“UUID”索引更改为 AUTO_INCREMENT，但是当我必须从我的 WPF 应用程序中插入员工时，就会出现问题。

address中的PK addressId会不断增加。那么我应该将什么传递给 FK 以保持关系紧密和正确？

我是否应该创建一个 int 类型的变量，比如说 var i = 0 并且每次我插入一名员工时 -> 将该变量加一 -> 将其分配给 FK 还是？ p>

Answer 1

为了在员工和地址之间建立多对多关联（地址类型如家庭、工作、帐单、旅行等），您需要这样的东西。然后，您可以创建其他实体表来跟踪这些实体和地址之间的关联。在表employee_address 中，这些列将作为外键返回到它们的相关表。

至于使用GUIDs 与INT 作为主键，数值读取速度比JOIN 上的字符串值快。根据您的数据量，您可能需要在未来几年从INT 切换到BIGINT。

另外，给这些人一些空间来输入他们的名字。 20 个字符太短了，尤其是姓氏。

employee
--------
employee_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
firstname VARCHAR(255) NOT NULL, 
lastname VARCAHR(255) NOT NULL,
gender BIT NOT NULL,
birthdate DATE NOT NULL

address
---------
address_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
address1 VARCHAR(255),
address2 VARCHAR(255),
address3 VARCHAR(255),
city VARCHAR(255),
state CHAR(2),
country CHAR(2)

address_type
--------------
address_type_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
address_type VARCHAR(255)

employee_address
-----------------
employee_address_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
employee_id INT,
address_id INT,
address_type_id INT