Question

我认为我在设计的数据库架构中没有做到最好。

我也在使用MySQL;

我有两个主要表：IMEI和用户;

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    |                |
+-------+---------------+------+-----+---------+----------------+

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

问题在于我为每个IMEI获取了一些数据，我想保存它们。我无法将所有IMEI数据保存在一个表中，因为这将是一个巨大的表。认为每个IMEI每30秒发送一次数据。它可能会很快填满我的桌子，因为这将是120（每小时）* 24 * 30 * 1000 = 86,400,000这对于桌子来说是相当大的。我想为名称为data_{IMEI}的每个IMEI创建单独的表，但那样可以创建许多表。

我不知道MySQL对多个表的效率有多大，但在这里我们谈论的是1000（我的估计）表。

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

提前致谢。

Answer 1

I can't save all IMEIs data in one table, since that will be huge table.

你为什么这么想？一个大表通常比充满表的数据库更好。如果每张桌子都相同，请认真考虑制作一张大桌子。

然后，如果它变慢，你可以去分区（进入物理单独的部分），但保持逻辑表为一个表。

过早优化是万恶之源;）

Answer 2

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

通过为每个IMEI创建一个表，您使数据库更难与之交互并且更复杂。

总的来说。数据库布局应该是相对静态的，存储的数据应该是变化的。

Answer 3

顺便说一句，我建议引入一个链接表，并在IMEI和用户之间建立多对多的关系。如果/当IMEI转移到另一个用户时会发生什么？

在回答您的原始问题时，每个IMEI都有一个表格，但是没有考虑按IMEI动态创建表格。

Answer 4

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

如果有一些关系数据库擅长，那就是在一个表中管理大量的行。假设您正确使用索引，性能将以对数进行缩放（即，执行各种操作的时间将比数据量慢得多。）

您尝试做的实际上是（横向）分区的形式。幸运的是，您可以let the DBMS do that for you，同时仍保留一个“逻辑”表格，避免出现“手动分区”所带来的复杂情况。

分区可以帮助提高性能，并且还可以帮助解决单个表太大以至于超出单个物理驱动器容量的情况，putting different partitions on separate physical drives ¹。

¹ Unfortunately：“使用InnoDB存储引擎为表定义分区时，DATA DIRECTORY和INDEX DIRECTORY选项无效。”如果你的表变得那么大，我建议你使用比MySQL更强大的DBMS

您如何看待我的数据库架构？

4 个答案: