我最近被分配为适合的数据库建模 存储超过 140 家公司的股票价格。数据将被收集 所有这些公司每天每 15 分钟一次，持续 8.5 小时。我的问题 现在面临的是如何设置数据库以实现快速搜索/获取 给定这个数据。
一种解决方案是将所有内容存储在一个包含以下列的表中：
| Company name | Price | Date | Etc... |
或者我可以为每个公司创建一个表格，然后只存储价格和日期 何时收集数据（以及其他未知 atm 的参数）。
您对这些解决方案有何看法？我希望问题得到解释 足够详细，否则请告诉我。
任何其他解决方案将不胜感激！
【问题讨论】：
标签： sql database database-design
鉴于您可能生成大量记录，我认为您担心性能 - 140 家公司 * 4 个数据点/小时 * 8.5 小时 * 250 个交易日/年意味着您正在查看大约 120 万条数据每年的积分。
现代关系数据库系统可以轻松地在单个表中处理这么多的记录 - 受一些重要考虑因素 - 我认为存储 100 年的数据点没有问题。
所以，是的，你的初始设计可能是最好的：
公司名称 |价格 |日期 |等等……|
根据公司名称和日期创建索引；这将允许您回答以下问题：
为了帮助防止性能问题，我会构建一个测试数据库，并用示例数据填充它（dbMonster 之类的工具使这变得容易），然后构建您（认为您）将针对真实系统运行的查询;使用数据库系统的调优工具来优化这些查询和/或索引。
【讨论】：
除了已经说过的话，我想说以下几点：不要使用“公司名称”或“股票代码”之类的东西作为您的主键。您可能会发现，股票价格有两个经常被忽视的重要特征：
因此，适当的通用解决方案应使用（ISIN、货币、证券交易所）三元组作为报价标识符。
【讨论】：
第一个更重要的问题是将针对此表执行的查询的类型和使用模式是什么。这是一个在线事务处理 (OLTP) 应用程序，其中绝大多数查询是针对单个记录，还是最多针对一小组记录？或者是在线分析处理应用程序，其中大多数查询需要读取和处理大量数据以生成聚合并进行分析。这两种截然不同的系统应该以不同的方式建模。
如果它是第一种类型的应用程序 (OLTP)，那么您的第一种选择会更好，但是查询的使用模式和类型对于确定要放置在表上的索引类型仍然很重要。
如果它是一个 OLAP 应用程序（并且一个存储数十亿股票价格的系统听起来更像一个 OLAP 应用程序），那么您设置的数据结构可能会更好地组织以存储预先聚合的数据值，或者甚至是所有的使用基于star schema 的多维数据库（如OLAP cube）的方式。
【讨论】：
将它们放在一个表中。现代数据库引擎可以轻松处理您指定的那些卷。
行号 |股票代码 |价格时间InUTC |价格代码 |询价 |投标价格 |音量
分别有一个 StockCode 表和一个 PriceCode 表。
【讨论】：
这是一种蛮力方法。第二次添加可搜索因素它可以改变一切。一个更灵活和优雅的选择是星型模式，它可以扩展到任何 数据量。我自己是一个私人团体。
【讨论】：