Mysql 你觉得我的数据库架构怎么样？

我认为在我设计的DB架构中，我没有做到最好

我也在使用MySQL

我有两个主表：IMEIs和user

IMEIs结构：

+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| imei    | varchar(20) | NO   | PRI | NULL    |       |
| user_id | int(11)     | NO   | MUL | NULL    |       |
+---------+-------------+------+-----+---------+-------+

+-------+---------------+------+-----+---------+----------------+
| Field | Type          | Null | Key | Default | Extra          |
+-------+---------------+------+-----+---------+----------------+
| id    | int(11)       | NO   | PRI | NULL    | auto_increment |
| pass  | varchar(2000) | NO   |     | NULL    |                |
+-------+---------------+------+-----+---------+----------------+

用户结构：

+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| imei    | varchar(20) | NO   | PRI | NULL    |       |
| user_id | int(11)     | NO   | MUL | NULL    |       |
+---------+-------------+------+-----+---------+-------+

+-------+---------------+------+-----+---------+----------------+
| Field | Type          | Null | Key | Default | Extra          |
+-------+---------------+------+-----+---------+----------------+
| id    | int(11)       | NO   | PRI | NULL    | auto_increment |
| pass  | varchar(2000) | NO   |     | NULL    |                |
+-------+---------------+------+-----+---------+----------------+

现在，我将加入这些表，这意味着每个用户可以有多个IMEI，我认为这种结构很好

问题是我从哪里获得每个IMEI的一些数据，并且我想保存它们。 我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表。假设每个IMEI每30秒发送一次数据。它很快就会填满我的桌子，因为那将是120（每小时）*24*30*1000=86400000，这对于一张桌子来说是相当大的。 我想为每个名为

data{IMEI}

的IMEI创建单独的表，但这样可以创建许多表

我不知道MySQL在多个表中的效率有多高，但这里我们讨论的是1000个表（我的估计很好）

现在这不是问题，但6个月或一年后，我可能会遇到问题。我必须预见我的设计

---

提前感谢。

我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表。

你为什么这么想？一个大表通常比一个满是表的数据库要好。如果每个表是一样的，认真考虑做一个大表。< /P> 然后，如果它运行缓慢，您可以将其分区（分成物理上独立的部分），但将逻辑表作为一个表保留

---

过早优化是万恶之源；）

我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表。

你为什么这么想？一个大表通常比一个满是表的数据库要好。如果每个表是一样的，认真考虑做一个大表。< /P> 然后，如果它运行缓慢，您可以将其分区（分成物理上独立的部分），但将逻辑表作为一个表保留

---

过早优化是万恶之源；）

您可以而且应该将所有IMEI保存在一个表中。存储大量结构化数据是一项数据库工作

通过为每个IMEI创建一个表，您使数据库更难交互，也更复杂

---

总的来说。数据库布局应该是相对静态的，存储的数据应该是更改的内容。

您可以而且应该将所有IMEI保存在一个表中。存储大量结构化数据是一项数据库工作

通过为每个IMEI创建一个表，您使数据库更难交互，也更复杂

---

总的来说。数据库布局应该是相对静态的，存储的数据应该是更改的内容。

另外，我建议引入一个链接表，并在IMEI和用户之间建立多对多关系。如果/当IMEI传输到另一个用户时会发生什么情况

---

在回答您最初的问题时，每个IMEI都有一行的单个表是可行的，不要考虑为每个IMEI动态创建一个表。

另外，我建议引入一个链接表，并在IMEI和用户之间建立多对多关系。如果/当IMEI传输到另一个用户时会发生什么情况

在回答您最初的问题时，每个IMEI都有一行的单个表是最好的选择，不要考虑为每个IMEI动态创建一个表

我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表

如果说关系数据库擅长什么，那就是在一个表中管理大量的行。假设正确使用索引，性能将以对数方式扩展（即，执行各种操作的时间将比数据量增长慢得多）

您试图做的实际上是一种（水平）分区形式。幸运的是，您可以这样做，同时仍然保留一个“逻辑”表并避免“手动分区”带来的复杂性

分区有助于提高性能，在单个表太大以至于超出单个物理驱动器1倍容量的情况下，分区也有助于提高性能

---

1:“使用InnoDB存储引擎为表定义分区时，数据目录和索引目录选项无效。”。如果您的表变得如此庞大，我建议您使用比MySQL更强大的DBMS

我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表

如果说关系数据库擅长什么，那就是在一个表中管理大量的行。假设正确使用索引，性能将以对数方式扩展（即，执行各种操作的时间将比数据量增长慢得多）

您试图做的实际上是一种（水平）分区形式。幸运的是，您可以这样做，同时仍然保留一个“逻辑”表并避免“手动分区”带来的复杂性

分区有助于提高性能，在单个表太大以至于超出单个物理驱动器1倍容量的情况下，分区也有助于提高性能

---

---

1:“使用InnoDB存储引擎为表定义分区时，数据目录和索引目录选项无效。”。如果您的表变得如此庞大，我建议您使用比MySQL更强大的DBMS

是什么让您认为一个表会（太）庞大？我有一个MySQL表，其中有160万条记录，对它的查询非常快，即使与其他表有多个连接。@eggyal每30秒会有一个IMEI数据。这导致1000个IMEI每天总共有28800000条记录。我认为这是巨大的@谢谢你。我认为我的案子比这更大@catfood连接发生在IMEIs和用户之间

SELECT*FROM IMEIs internal JOIN users ON users.id=IMEIs.user\u id

但这不是问题所在。问题是