5

我们将数据存储在数据仓库中，如下所示：

  • 价格
  • 日期
  • 产品名称 (varchar(25))

我们目前只有四种产品。这种变化很少发生（平均每 10 年一次）。每个工作日一次，添加四个新数据点，代表每种产品的当天价格。

在网站上，用户可以通过输入日期范围并选择一个或多个产品名称来请求此信息。分析显示该功能并未大量使用（每周大约 10 个用户请求）。

建议数据仓库每天将包含所有数据的 CSV 文件（目前 6718 行，每天增加 4 行）推送（SFTP）到 Web 服务器。然后，Web 服务器将从文件中读取数据，并在用户提出请求时显示该数据。

通常，推送只会一天一次，但不止一次推送可能会传达（不频繁的）价格修正。即使在价格修正方案中，所有数据都将在文件中交付。这种方法有什么问题？

让 Web 服务器根据用户请求向数据仓库发出请求会更好吗？或者这是否存在网络错误或性能问题的可能性更大等问题？

4

2 回答 2

5

让 Web 服务器根据用户请求向数据仓库发出请求会更好吗？

是的。您的数据很少，因此无需尝试以某种方式“缓存”它。（除了 CSV 可能不是执行此操作的最佳方式这一事实之外）。没有什么能阻止您从网络服务器向数据库服务器发出这些请求。有了这么少的信息，您不会发现性能问题，但即使一切都在增长，在数据库方面（索引等）也有很多收获，这将帮助您在接下来的 100 年中生存下来这种时尚。

来自您的用户的请求数量（也非常少）不需要任何特殊处理，因此再次直接查询是最好的。

或者这是否存在网络错误或性能问题的可能性更大等问题？

好吧，它可能会，但这不能证明你的 CSV 方法是合理的。示例以及您不必担心的原因可能是

  • 与数据库服务器的连接已断开。
    这对这两种方法来说都是一个问题，但是对于每天一次的方法来说，每天只有一个连接，万分之一的故障的变化似乎更好。但是这些问题不应该经常出现，如果出现了，你应该能够处理它们。（重试请求，给用户一个消息）。这就是大量网站所做的事情，所以如果我说这不会成为问题，请相信我。另外，想想如果您的每日更新失败意味着什么？那会带来更大的问题！
  • 正如所说的性能问题
    ，这是由于数据量和请求量造成的，而不是问题。即使它变成了一个，这也是一个你应该能够在不同层次上发现的问题。在数据库服务器上使用缓存系统（非 CSV）。在网络服务器上使用缓存系统。修复索引以防止性能成为问题。

但：

将您的数据仓库与您的 Web 系统分开并不奇怪。如果这是一个要求，而且它肯定可能是，你能做的最好的事情是在另一台机器上重新创建你的仓库数据库（我刚刚辩护为足以直接查询的那个）。做主从系统可能会得到很好的结果

  • 您的数据仓库是一个主数据库：它将所有更改发送到从属，但其他情况下是不可逾越的
  • 您的第二个数据库（甚至在您的网络服务器上）从主服务器获取所有更新，并且是只读的。你只能查询它的数据
  • 您的网络服务器无法连接到数据仓库，但可以连接到您的从站以读取信息。即使有注入黑客，也没关系，因为它是只读的。

现在您没有任何时间更新查询的数据库（主从复制将始终保持更新），但是来自网络服务器的查询不可能使您的仓库处于危险之中。利润！

于 2014-01-10T14:28:11.450 回答
1

我真的不明白 SQL 注入如何成为一个真正的问题。我假设您有一些日历类型字段供用户填写以获取数据。如果这是唯一的形式，只需确保其中的唯一字段是日期，那么类似的事情DROP TABLE是不可能的。至于访问数据库，这是另一个问题。但是，在大多数情况下，仅包含连接功能的单独文件应该可以正常工作，这样用户就无法在 HTML 查看器中打开您的网页并查看您的数据库连接字符串。

至于 CSV，我不得不说为每个用户查询一个数据库，特别是如果它每周只使用约 10 次，这将比 CSV 更有效。我只是将 CSV 等同于矫枉过正，因为同样你只有大约 10 个用户试图获取一些信息，每天导出更新的 CSV 对于这么少的回报来说太过分了。

编辑：

此外，如果攻击是一个大问题，这实际上取决于业务的性质、存储的数据以及您收到的访问者，您始终可以创建备份作为另一种选择。正如您目前所说的那样，我真的没有看到这样做的原因，但即使有最好的安全性，也有可能发生攻击。这主要取决于攻击者是否想要您拥有的信息。

于 2014-01-10T14:11:54.233 回答