Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/mysql/65.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181

Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/database/8.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Mysql 在这种情况下,GUID是地址的良好参考键吗?_Mysql_Database_Relationship - Fatal编程技术网

Mysql 在这种情况下,GUID是地址的良好参考键吗?

Mysql 在这种情况下,GUID是地址的良好参考键吗?,mysql,database,relationship,Mysql,Database,Relationship,我目前在一家建筑管理软件公司工作,在为我的数据库设计架构时遇到了一个问题(如下所述),该数据库目前包含四个表,即员工表、地址表、用户表和许可证 造成混淆的表格是员工和地址;下面提供了代码 为了维护数据的完整性,我没有在employee表中存储任何从地址派生的词汇,例如Address1、Address2、城市、州、县等;因为我主观上认为,不唯一标识特定员工的属性最好成为另一个表的一部分。现在我的问题是: 使用a作为地址表的主键是否是一个好的选择 如果是,是否有可能是阻止快速查询的因素 我选择使

我目前在一家建筑管理软件公司工作,在为我的数据库设计架构时遇到了一个问题(如下所述),该数据库目前包含四个表,即员工表地址表用户表许可证

造成混淆的表格是员工地址;下面提供了代码

为了维护数据的完整性,我没有在employee表中存储任何从地址派生的词汇,例如Address1、Address2、城市、州、县等;因为我主观上认为,不唯一标识特定员工的属性最好成为另一个表的一部分。现在我的问题是:

  • 使用a作为地址表的主键是否是一个好的选择
  • 如果是,是否有可能是阻止快速查询的因素
我选择使用GUID作为PK索引的原因是我没有选择。地址中的EmployeeId没有为我提供解决方案,因为我不能将字段作为PK和FK:

我想知道是否有其他方法可以在不使用GUID的情况下在员工地址之间建立适当的关系。另一种方法是指定(int)值,但在这种情况下,缺点是:

  • 错误地介绍FK!=PK,这将导致表之间的关系不良
编辑:

你们中的一些人在评论中建议将“UUID”索引更改为自动增量,但当我必须从我的WPF应用程序中插入员工时,问题就出现了

地址的主键地址ID将自行增加。那么,我应该通过什么途径进入FK来保持这种关系的紧密和正确呢


我应该创建一个int类型的变量,比如说var I=0,每次我插入一个employee->将该变量增加一个->将其分配给FK还是?

为了在employee和地址之间进行多对多关联,您需要这样的东西(地址类型将类似于家庭、工作、账单、旅行等)。然后,您可以创建其他实体表来跟踪这些实体和地址之间的关联。在表
employee\u Address
中,这些列将是其相关表的外键

至于使用
GUID
s vs
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

顺便说一句,varchar(1)似乎是一个愚蠢的想法。您觉得如何添加一个表来放置员工和地址之间的关系?f.e.带有2 FK:(Id,employeeId,AddressId)。地址表可以简化。您的员工和地址表都将有自己的主键。然后,您的地址表将有一个外键,该外键保存关联员工记录的主键。问题是什么?1中没有太多的“var”,是吗?在这种情况下,Char对meI更为合理rry如果这个问题看起来很傻,但为什么我需要地址类型?它代表什么?请你再详细说明一下好吗?PS:整体上看,这个方法比我的好。答案是这样的,但地址类型允许你具体说明:这是一个家庭地址,一个工作地址,用于计费,用于计算吗吃差旅费?你说你在建“施工管理软件”,你还需要像“工地地址”、“营业地址”这样的东西。完全正确,我没意识到你也注意到这些信息。这个答案对我帮助很大,我很感激。
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