Rob*_*rtH 5 sql database database-design
我最近接到的任务是为适合存储 140 多家公司的股票价格的数据库建模。从所有这些公司每天 8.5 小时,每 15 分钟收集一次数据。我现在面临的问题是如何设置数据库以实现给定这些数据的快速搜索/获取。
一种解决方案是将所有内容存储在一个表中,其中包含以下列:
| Company name | Price | Date | Etc... |
Run Code Online (Sandbox Code Playgroud)
或者我可以为每家公司创建一个表,并只存储收集数据时的价格和日期(以及其他未知 atm 的参数)。
您对这些解决方案有何看法?我希望问题得到了足够详细的解释,否则请告诉我。
任何其他解决方案将不胜感激!
考虑到您可能生成的大量记录,我认为您担心性能 - 140 家公司 * 4 个数据点/小时 * 8.5 小时 * 250 个交易日/年意味着您每年查看大约 120 万个数据点.
现代关系数据库系统可以在单个表中轻松处理这么多记录 - 受一些重要考虑因素的影响 - 我认为存储 100 年的数据点没有问题。
所以,是的,您的初始设计可能是最好的:
公司名称 | 价格 | 日期 | 等等... |
创建公司名称和日期索引;这将允许您回答以下问题:
为了帮助防止性能问题,我会构建一个测试数据库,并用示例数据填充它(像dbMonster这样的工具使这很容易),然后构建您(认为您)将针对真实系统运行的查询;使用数据库系统的调优工具来优化这些查询和/或索引。
除了已经说过的话,我想说以下几点:不要使用“公司名称”或“股票代码”之类的东西作为主键。您可能会发现,股票价格有两个经常被忽视的重要特征:
因此,正确通用的解决方案应该使用(ISIN、货币、证券交易所)三元组作为报价的标识符。
第一个更重要的问题是将针对该表执行的查询的类型和使用模式是什么。这是一个联机事务处理 (OLTP) 应用程序吗?其中绝大多数查询都是针对单个记录或至多针对一小组记录?或者是在线分析处理应用程序,其中大多数查询需要读取和处理大量数据以生成聚合并进行分析。这两种截然不同类型的系统应该以不同的方式建模。
如果它是第一种类型的应用程序 (OLTP),那么您的第一个选择是更好的选择,但查询的使用模式和类型对于确定要放置在表上的索引类型仍然很重要。
如果它是一个 OLAP 应用程序(并且存储数十亿股票价格的系统听起来更像是一个 OLAP 应用程序),那么您设置的数据结构可能会更好地组织来存储预先聚合的数据值,甚至一路使用多维数据库,如OLAP 多维数据集,基于星型模式。
| 归档时间: |
|
| 查看次数: |
8896 次 |
| 最近记录: |