Question

我的应用程序在名为“ emp_login”的表中存储了2500多名员工的登录信息。现在，我必须每天存储每个员工的活动。为此，我为每个员工创建了一个单独的表。例如。 emp00001，emp0002 ...每个表将有大约50列。在大量研究了stackoverflow之后，我有点困惑。许多专家说，在mysql上具有200-300多个表的数据库被认为设计不良。

我的问题是，拥有这么大的桌子是否是个好主意？我的数据库设计不好吗？我应该选择其他数据库，例如mssql吗？还是有一些其他想法可以处理此类应用程序的数据库？

Answer 1

不要那样做。每个员工都应该在一张表中，并具有主键索引ID，即：

1: Tom
2: Pete

然后，您为操作分配一个引用员工ID号的列

Action, EmployeeID

您应始终将具有索引ID的表中的相同实体分组，然后通过ID将属性/操作链接到这些实体。想象一下您要为每个员工搜索一个包含不同表的数据库所要做的事情。会破坏使用SQL的全部目的。

事件表如下：

Punchin, 1, 2018/01/01 00:00

那会告诉你汤姆（Tom）在2018/01/01 00:00打孔。这是一个非常简单的示例，您可能并不想那样构造事件表，但应该可以使您走上正确的轨道。

Answer 2

这与MySQL无关，而与有缺陷的设计有关。您应该为所有员工提供一张桌子。其中包含员工独有的信息，例如名字，姓氏和电子邮件地址。

|ID | "John"   | "Smith"    | "john.smith@gmail.com"        |
|1 | "James"   | "Smith"    | "james.smith@gmail.com"       |
|2 | "jane"    | "Jones"    | "jane.jones.smith@yahoo.com"  |
|3 | "Joanne"  | "DiMaggio" | "jdimaggio@outlook.com"       |

注意ID列。通常，这是一个设置了AUTO_INCREMENT的整数，您将其设为主键。然后，每次添加新用户时，您都会获得一个新的唯一编号。

现在，每个相关数据都有单独的表。例如。他们居住的城市或他们的登录时间（我想从表格名称中获取您的信息）。

如果这是一对多的关系（即每个用户都有很多登录时间），则您将创建一个额外的表，该表引用您的第一个表。这是一个DEPENDENT表。像这样：

| UserId | LoginTime              |
| 1      | "10:00:04 13-09-2018"  |
| 2      | "11:00:00 13-09-2018"  |
| 3      | "11:29:07 14-09-2018"  |
| 1      | "09:00:00 15-09-2018"  |
| 2      | "10:00:00 15-09-2018"  |

现在，当您查询数据库时，您可以在UserId字段上进行JOIN连接两个表。如果仅是他们的LAST登录时间，那么您可以将其放在用户表中，因为它只是一条数据。但是因为它们将有很多登录时间，所以登录时间需要是自己的表。（注：我没有在此表上放置ID列，但这是一个好主意。）

如果不是每个用户都唯一的数据，即是一个多对多的关系（例如他们所居住的城市），则需要两个表。一个包含城市，另一个包含将两者连接的INTERMEDIARY表。如下所示：

（城市表）

| ID  | City          |
| 1   | "London"      |
| 2   | "Paris"       |
| 3   | "New York"    |

（城市用户表）

| UserID   | CityID |
| 1        | 1      |
| 2        | 1      |
| 3        | 3      |

然后，您将执行两个JOINS来连接所有三个表，并获取每个员工所居住的城市。同样，我没有在中间表中添加ID字段和PRIMARY KEY，因为这不是绝对必要的（您可以创建一个独特的组合键（这是一个不同的讨论），但这是一个好主意。

这是您需要了解的基本知识。始终按功能划分数据。请勿将其除以数据本身（即每个用户的表）。您现在要查找的东西称为“数据库规范化”。将其放入搜索引擎并阅读良好的概述。它不会花很长时间，并且会对您有很大的帮助。

超过2500表在mysql中

2 个答案: