你对我的DB体系结构有什么看法？
我认为在我设计的DB体系结构中，我没有尽力而为。
我也在使用MySQL；
我有两个主要表: 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的一些数据，并且我想保存它们。我无法将所有IMEIs数据保存在一个表中，因为这将是一个巨大的表。假设每个IMEI每30秒发送一次数据。它很快就能填满我的桌子，因为那将是120(每小时)* 24 * 30 * 1000 = 86,400,000，这对于一张桌子来说是相当大的。我希望为每个名为data_{IMEI}的IMEI创建单独的表，但是这样就可以生成许多表。
对于使用多个表，我不知道MySQL的效率有多高，但是这里我们讨论的是1000个表(据我估计，这是一个很好的估计)。
这暂时不是问题，但6个月或1年后，我可能会遇到问题。我必须预见到我的设计。
提前谢谢。
回答 3
Stack Overflow用户
发布于 2013-12-06 14:52:45
I can't save all IMEIs data in one table, since that will be huge table.
你为什么这么想？一个大表通常比充满表的数据库好。如果每个表是相同的，认真考虑做一张大桌子。
然后，如果速度慢，您可以将其划分(分为物理分离部分)，但将逻辑表保持为一个表。
过早优化是万恶之源;)
Stack Overflow用户
发布于 2013-12-06 14:56:53
您可以而且应该将所有IMEI保存在一个表中。存储大量结构化数据是一项数据库工作。
通过为每个IMEI创建一个表，您将使数据库更难与之交互，并且更加复杂。
总体而言。数据库布局应该是相对静态的，存储的数据应该是什么变化。
Stack Overflow用户
发布于 2013-12-06 15:07:37
顺便提一下，我建议引入一个链接表，并在IMEI和用户之间建立多到多的关系。如果/当IMEI被传输到另一个用户时会发生什么？
在回答您最初的问题时，为每个IMEI提供一行的单个表是可行的，不要考虑为每个IMEI动态创建一个表。
https://stackoverflow.com/questions/20426825
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号