我们将数据存储在数据仓库中,如下所示:
我们目前只有四种产品。这种情况很少发生变化(平均每10年一次)。每个工作日,都会添加四个新数据点,代表每种产品的当天价格。
在网站上,用户可以通过输入日期范围并选择一个或多个产品名称来请求此信息。 Google Analytics(分析)显示该功能未得到大量使用(每周约10个用户请求)。
有人建议,数据仓库应每天推送(SFTP)一个包含所有数据的CSV文件(目前每天有6718行,每天增加4个)到Web服务器。然后,Web服务器将从文件中读取数据,并在用户发出请求时显示该数据。
通常情况下,推送只会每天一次,但可以通过多次推送来进行(不经常)价格修正。即使在价格修正方案中,所有数据都将在文件中传递。这种方法有什么问题?
让Web服务器根据用户请求向数据仓库发出请求会更好吗?或者这是否存在诸如网络错误或性能问题的可能性更大的问题?
答案 0 :(得分:5)
让Web服务器根据用户请求向数据仓库发出请求会更好吗?
是的。您的数据非常少,因此无需尝试以某种方式“缓存”此数据。 (除了CSV可能不是最好的方法)。 没有什么可以阻止您从Web服务器向数据库服务器执行这些请求。有了这么少的信息,你就不会发现性能问题,但即使它会在一切都在增长的时候,在数据库方面(索引等)还有很多东西可以帮助你在未来100年中生存下来。这种时尚。
来自用户的请求数量(也非常小)不需要任何特殊处理,因此,直接查询也是最好的。
或者是否存在诸如网络错误或性能问题的可能性更大的问题?
嗯,它可能,但这不符合你的CSV方法。例子和为什么你不用担心,可能是
将数据仓库与Web系统分离并不奇怪。如果这是一个要求,而且肯定可以,那么你可以做的最好的事情就是在另一台机器上重新创建你的仓库数据库(我刚刚辩护的那个就好了,可以直接查询)。通过执行主从系统可能会获得良好的结果
现在您没有更新查询数据库的时刻(主从复制将始终保持更新),但是来自Web服务器的查询不会使您的仓库陷入危险。利润!
答案 1 :(得分:1)
我真的不知道SQL注入如何成为一个真正的问题。我假设您有一些日历类型字段,用户填写该字段以获取数据。如果这是唯一的形式,只需确保其中唯一的字段是日期,那么DROP TABLE
之类的字段就不可能。至于访问数据库,这是另一个问题。但是,在大多数情况下,只有连接函数的单独文件应该可以正常工作,这样用户就无法在HTML查看器中打开您的网页并查看数据库连接字符串。
对于CSV,我不得不说每个用户查询一个数据库,特别是如果它每周只使用~10次,那么它将比CSV更有效率。我只是将CSV等同于过度杀戮,因为你只有大约10个用户试图获取一些信息,每天导出更新的CSV对于这么少的回报来说太多了。
编辑:
此外,如果攻击是一个大问题,这实际上取决于业务的性质,存储的数据以及您收到的访问者,您始终可以创建备份作为另一种选择。我现在没有看到这个问题的原因,因为你的问题目前已经提出,但即使有最好的安全性,攻击也可能发生。这主要取决于攻击者是否需要您拥有的信息。