2

我正在创建一个数据库，用于跟踪南佛罗里达州一个城市的人均用水量。

大约有 40000 名用户，每个用户都上传每日读数。

我正在考虑设置数据库的方法，并且给每个用户单独的表似乎更容易。这应该会简化数据的下载，因为服务器不必对包含数十万个条目的表进行排序。

我的逻辑是错误的吗？
有没有办法索引表名？
有没有其他方法可以设置数据库以提高速度并保持布局足够简单？

-谢谢你，
杰瑞德

ps 读数的基本数据是：
-locationID（我的想法中的表名）
-Reading
-ReadDate
-ReadTime

pps 在这次谈话中，我上传了 5k 表并且服务器冻结了。~.O
谢谢你的帮助，你们会的

4

4 回答 4

8

设置数千个表不是一个好主意。您应该维护一个表并将所有条目放在该表中。MySQL 可以处理数量惊人的数据。您将遇到的最大问题是一次可以处理的查询量，而不是数据库的大小。对于您将处理数字的实例使用intwith attribute unsigned，以及您将处理文本使用varchar适当大小的实例（除非文本是大的 use text）。

处理用户 如果您需要识别用户的记录，请设置另一个可能如下所示的表：

  • user_id INT(10) AUTO_INCREMENT UNSIGNED PRIMARY
  • 名称 VARCHAR(100) 非空

当您需要将记录链接到用户时，只需引用用户的user_id. 对于记录信息，我将设置 SQL，例如：

  • id INT(10) AUTO_INCREMENT UNSIGNED PRIMARY
  • u_id INT(10) 未签名
  • 阅读我不确定你的阅读内容是什么样的。如果它是一个数字使用INT如果它的文本使用VARCHAR
  • 读取时间时间戳

您还可以将阅读的日期和时间合并到一个TIMESTAMP.

于 2012-08-21T03:35:46.533 回答
5

不要为每个用户创建单独的表。

在标识用户的列和任何其他常见约束（如日期）上保留索引。

最后想想你想如何查询数据。你到底如何总结一天所有用户的数据？

如果您担心主键，我建议您保留 LocationID、Date 复合键。

编辑：最后，（我的意思确实很好）但是如果你问这些关于数据库设计的问题，你确定你有资格参与这个项目吗？看起来你可能会不知所措。有时，最好了解您的局限性并让项目通过，而不是以一种为您创造太多工作而人们对结果不满意的方式实施它。再说一次，我不是说不要，我只是说你有没有问过自己，你是否能做到他们期望的水平。似乎有大量用户不断使用它。我想我的意思是，在向成千上万的用户交付项目的同时学习某些东西可能是一个异常高压的环境。

于 2012-08-21T03:37:04.600 回答
4

一般来说，表格应该代表一组事物。在您的示例中，很容易识别您拥有的集合：用户和读数；理论上最好的结构是拥有这两个表，其中读数条目引用了用户的 ID。

MySQL 可以处理非常大量的数据，所以最好的办法是尝试用户读数结构，看看它是如何执行的。或者，您可能希望查看基于文档的 NoSQL 数据库，例如 MongoDB 或 CouchDB，因为将读数报告存储为单个文档也是一个不错的选择。

于 2012-08-21T03:40:09.437 回答
2

如果您创建一个包含每个用户每月总数的汇总表，那肯定是系统的主要用途，对吧？

每个月，您都会处理数字并将总数存储到第二个表中。您可以在滚动的 12 个月期间修剪日志表。即，可以将旧数据塞在角落以保持索引更小，因为您只需要在城市被指控欺诈时访问它。

因此，您究竟如何存储每日读数并不是您需要担心的大问题。给每个用户他自己的表不是正确的解决方案。如果您有大量数据，那么您可能需要考虑通过 MongoDB 之类的方式进行分片。

于 2012-08-21T03:57:05.493 回答